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Vorwort 


Warum sollte man dieses Buch lesen? 


Während dieses Buch geschrieben wurde, d.h. im Jahr 2020, wurden intelligen- 
te Systeme (auch smarte Systeme genannt) zunehmend verfügbar. Solche Systeme 
benutzen Computer und andere Formen der Informations- und Kommunikations- 
technologie (IKT), um den Menschen ihre Dienste bereitzustellen, zum Teil mit 
Hilfe verschiedener Formen künstlicher Intelligenz (KI). Beispielsweise sind kürz- 
lich vorgestellte Autos zunehmend in der Lage, autonom zu fahren. In der Luftfahrt 
und bei schienengebundenem Verkehr sind Systeme ohne Piloten bzw. Fahrer ange- 
kündigt oder bereits verfügbar. Das Stromnetz wird intelligenter und dasselbe gilt 
für Gebäude. Alle diese Systeme basieren auf einer Kombination von IKT und phy- 
sischen Systemen, die cyber-physikalische Systeme (engl. Cyber-Physical System 
(CPS)) genannt werden. Solche Systeme sind „ingenieurmäßig konstruierte Syste- 
me, die auf der Synergie von rechnenden und physischen Komponenten aufbauen 
und davon abhängen” [413]. Aufgrund der engen Integration mit der physischen Welt 
müssen diese Systeme sehr verlässlich sein. 

Das englische Original physical kann dabei im Deutschen sowohl mit „physisch” 
wie auch mit „physikalisch” übersetzt werden. „Physisch” trifft die Intention häufig 
besser, da wir meist auf eine Integration mit der Welt der (physischen) Dinge zielen 
und nur eine Integration mit einem Teil der Physik anstreben. Wir werden deshalb die 
Übersetzung „physisch” verwenden, sofern wir nicht explizit einen Bezug zur Physik 
meinen. Außerdem benutzen wir die Bezeichnung „cyber-physikalisches System”, 
da sie verbreiteter ist und besser klingt. 

Physische Dinge spielen auch eine entscheidende Rolle bei der Definition des Be- 
griffs des „Internets der Dinge” (engl. Internet of Things (IoT)). IoT „beschreibt die 
um sich greifende Gegenwart einer Vielfalt von Geräten — wie Sensoren, Aktuatoren 
und Mobiltelefonen -, die mittels eindeutiger Adressierung in der Lage sind, mitein- 
ander zu interagieren und zu kooperieren, um gemeinsame Ziele zu erreichen” [185]. 
Sensor-Netzwerke und E-Roller, die anhand im Internet verzeichneter, GPS-basierter 
Standorte eingesammelt werden, sind Beispiele des Internets der Dinge. 


viii Vorwort 


Beide Begriffe, CPS und IoT, sind Verallgemeinerungen des früher geprägten 
Begriffs der „eingebetteten Systeme” (ES). Unter dem Begriff „eingebettete Syste- 
me” verstehen wir dabei informationsverarbeitende Systeme, die in ein umgebendes 
Produkt (wie ein Auto oder ein Flugzeug) eingebettet sind [372]. Verglichen mit 
dem Begriff der eingebetteten Systeme betonen die Begriffe CPS und IoT stärker die 
physischen Objekte. 

Der starke Anstieg in der Verfügbarkeit von eingebetteten Systemen wurde bereits 
2001 vorhergesagt: „Die Informationstechnologie (IT) befindet sich an der Schwelle 
einer weiteren Revolution. .... vernetzte Systeme von eingebetteten Rechnern ... haben 
das Potential, die Art und Weise, in der Personen mit ihrer Umgebung interagieren, 
radikal zu verändern, indem sie eine Reihe von Geräten und Sensoren miteinander 
verbinden und erlauben, Informationen in nicht gekannter Weise zu sammeln, zu 
teilen und zu verarbeiten. Die Benutzung ... überall in der Gesellschaft kann bisherige 
Meilensteine in der Revolution der Informations(nutzung) als Zwerge erscheinen 
lassen.” Dieses Zitat aus einem Bericht des National Research Councils in den 
USA [411] beschreibt die dramatischen Auswirkungen der Informationstechnologie 
in eingebetteten Systemen sehr schön. Diese Revolution hatte bereits einen großen 
Einfluss und sie setzt sich fort. 

Begriffe wie das durchdringende und allgegenwärtige Rechnen (engl. pervasive 
und ubiquitous computing), die umgebende Intelligenz (engl. ambient intelligence) 
sowie „Industrie 4.0” [68] beziehen sich ebenfalls auf den dramatischen Einfluss der 
Änderungen, die durch Informationstechnologie hervorgerufen werden. 

Der Bedeutung eingebetteter/cyber-physikalischer Systeme und des Internets der 
Dinge wird bislang in Lehrplänen kaum Rechnung getragen. Dabei verlangt der 
Entwurf der erwähnten Systeme interdisziplinäres Wissen und Fähigkeiten jenseits 
der Grenzen zwischen traditionellen Fachgebieten. Eine solche breite Ausbildung 
erscheint allerdings als schwierig, v.a. aufgrund des großen Bereichs an relevan- 
ten Gebieten. Dieses Buch zielt auf den Wissenserwerb in einem Kernbereich der 
relevanten Gebiete. Dabei ist es bereits schwierig, einen solchen Kernbereich zu 
identifizieren. Dieses Buch soll eine Abhilfe schaffen. Es enthält Stoff für einen 
ersten Kurs über solche Systeme und bietet einen Überblick über Schlüsselkonzepte 
für eine Integration der IKT mit physischen Objekten. Es betrachtet Hardware- wie 
auch Softwareaspekte. Dies geschieht in Übereinstimmung mit den ARTIST! Richt- 
linien für Curricula in eingebetteten Systemen: „Die Entwicklung von eingebetteten 
Systemen kann die Charakteristika der zugrunde liegenden Hardware nicht ignorie- 
ren. Das Zeitverhalten, der Speicherbedarf, die Stromaufnahme und physikalische 
Ausfälle sind wichtig” [85]. 

Dieses Buch ist als Lehrbuch konzipiert, aber es enthält eine größere Anzahl 
an Referenzen als übliche Lehrbücher und soll auch helfen, das Themengebiet zu 
strukturieren. Daher soll es auch für Lehrende an Hochschulen und Ingenieure 
nützlich sein. Für Studierende wird der Zugang zu relevanten Informationsquellen 
durch die umfangreichen Referenzen erleichtert. 


1 ARTIST ist das Akronym für ein europäisches Exzellenznetzwerk zu eingebetteten Systemen 
(siehe https://artist-embedded.org und http://www.emsig.net). 


Vorwort ix 


Das Buch konzentriert sich auf die grundlegenden Eigenschaften von Software 
und Hardware. Bestimmte kommerzielle Produkte und Werkzeuge werden nur dann 
erwähnt, wenn sie herausragende Eigenschaften besitzen. Auch dies entspricht den 
ARTIST-Richtlinien: „Grundlagen sind in der Fortbildung (im Betrieb) nur sehr 
schwer anzueignen, wenn sie nicht von Anfang an gelernt wurden; wir müssen daher 
einen Schwerpunkt (in der Hochschulausbildung) darauf legen” [85]. Daher geht 
dieses Buch über die Programmierung von Mikrocontrollern hinaus und präsentiert 
die Grundlagen eingebetteter Systeme, die für den Entwurf von CPS- und IoT- 
Systemen benötigt werden. Mit diesem Ansatz wollen wir verhindern, dass das 
vorgestellte Material schnell an Aktualität verliert. 

Die vorgeschlagene Positionierung des vorliegenden Lehrbuchs in Lehrplänen 
der Informatik und verwandten Gebieten der IKT wird in einer Veröffentlichung 
[373] erläutert. Ein Hauptziel dieses Buches ist es, einen Überblick über den Ent- 
wurf eingebetteter Systeme zu geben und die wichtigsten Themen darin miteinander 
in Beziehung zu setzen. Damit vermeiden wir ein in den ARTIST-Richtlinien er- 
wähntes Problem: „Der Mangel an Reife des Gebiets führt zu einer großen Vielfalt 
an industriellen Praktiken, die vielfach aus kulturellen Gewohnheiten resultieren. ... 
Lehrpläne ... konzentrieren sich auf eine Technik und präsentieren keine ausreichend 
breite Perspektive. ... Im Ergebnis hat die Industrie Schwierigkeiten, angemessen 
ausgebildete Ingenieure zu finden, denen Entwurfsalternativen geläufig sind” [85]. 

Das Buch soll weiterhin die Lücke zwischen praktischen Erfahrungen mit der 
Programmierung von Mikrocontrollern und eher theoretischen Themen schließen. 
Zudem sollen Studierende und Lehrende dazu motiviert werden, sich tiefer in die 
Thematik einzuarbeiten. Während eine Reihe von Themen in diesem Buch ausführ- 
lich behandelt werden, können andere nur kurz angerissen werden. Diese kurzen 
Abschnitte wurden aufgenommen, um verwandte Problemstellungen miteinander in 
Beziehung zu setzen, ohne auf jede der Problemstellungen im Detail einzugehen. 
Dieser Ansatz erlaubt es Lehrenden auch, entsprechende Querverweise zu ergänzen- 
dem Material ihrer Wahl hinzuzufügen. Aufgrund der großen Zahl an Referenzen 
kann das Buch auch als umfassendes Tutorial benutzt werden, das Hinweise für wei- 
teres Lesen enthält. Diese Hinweise können auch dazu anregen, das Buch in Laboren 
und Projekten oder als Anfangspunkt für eigene Forschungsprojekte zu nutzen. 

Das Buch beschreibt Spezifikationstechniken, Hardwarekomponenten, System- 
software, Abbildung von Anwendungen auf Plattformen, Bewertung und Über- 
prüfung von Entwurfszielen sowie ausgewählte Optimierungen und Testmethoden. 
Dabei behandelt es eingebettete Systeme und ihre Schnittstelle zur physikalischen 
Umgebung aus einer breiten Perspektive, aber es kann nicht jedes verwandte Ge- 
biet abdecken. Rechtliche, soziale und ökonomische Aspekte, Mensch-Maschine- 
Schnittstellen, Datenanalyse, anwendungsspezifische Aspekte und eine detaillierte 
Darstellung physikalischer Themen wie auch die Kommunikationstechnik gehen 
über den Themenkreis dieses Buches hinaus. Das Internet der Dinge wird nur mit 
seinen Bezügen zu eingebetteten Systemen behandelt. 


x Vorwort 


Wer sollte dieses Buch lesen? 


Dieses Buch ist für die folgenden Leserkreise gedacht: 


e Informatik- und Elektrotechnik-Studierende sowie Studierende anderer IKT-naher 
Studiengänge, die sich im Bereich eingebetteter/cyber-physikalischer Systeme 
spezialisieren wollen. Das Buch ist für Studierende im dritten Studienjahr geeig- 
net, die über Grundkenntnisse der Rechner-Hard- und Software verfügen. Daher 
zielt dieses Buch hauptsächlich auf Studierende kurz vor dem Abschluss des Ba- 
chelorstudiums ab?. Es kann aber auch in weiterführenden Kursen zum Einsatz 
kommen, wenn die bisherigen Kurse den Entwurf eingebetteter Systeme nicht 
behandelt haben. Dieses Buch soll den Weg für weiterführende Themen berei- 
ten, die in aufbauenden Kursen behandelt werden können. Dabei setzt das Buch 
Grundkenntnisse der Informatik voraus. Elektrotechnik-Studierende müssen un- 
ter Umständen auf zusätzliche Unterlagen zurückgreifen, um alle Themen dieses 
Buchs in vollem Umfang zu verstehen. Dies wird aber zum Teil dadurch aufge- 
wogen, dass einige der Inhalte dieses Buches Studierenden der Elektrotechnik 
bereits bekannt sein sollten. 

e Ingenieure, die bisher Hardwaresysteme entwickelt haben und sich in Zukunft 
mehr mit der Softwareseite eingebetteter Systeme befassen müssen. Dieses Buch 
sollte eine ausreichende Grundlage liefern, um die relevanten technischen Veröf- 
fentlichungen zu verstehen. 

« Doktoranden, die schnell einen umfassenden Überblick über die wichtigsten Kon- 
zepte eingebetteter Systeme erhalten wollen, bevor sie ein spezielles Forschungs- 
gebiet wählen. 

e Professoren, die einen neuen Lehrplan für eingebettete Systeme erstellen wollen. 


Wie unterscheidet sich dieses Buch von früheren Auflagen? 


Die erste englische Ausgabe dieses Buches wurde 2003 veröffentlicht. Das Gebiet 
der eingebetteten Systeme entwickelt sich rasant fort, daher sind seit dem Erschei- 
nen der ersten Ausgabe viele neue Erkenntnisse hinzugekommen. Zudem hat sich 
die Bedeutung zwischen verschiedenen behandelten Bereichen verschoben. In eini- 
gen Fällen war eine intensivere Auseinandersetzung mit einem Themengebiet wün- 
schenswert. Neue Entwicklungen wurden zum Teil bereits in der ersten deutschen 
Übersetzung des Buches 2007 berücksichtigt, in der zweiten englischen Auflage 
(erschienen 2010/2011) übernommen und ausgebaut. 

Im letzten Jahrzehnt haben sich weitere technologische Änderungen ergeben. So 
gab es die klare Umstellung von einzelnen Rechnerkernen zu Mehrkern-Systemen. 
Außerdem haben cyber-physikalische Systeme und das Internet der Dinge mehr 
Aufmerksamkeit erfahren. Der Verbrauch an elektrischer Energie, das thermische 


? Dies passt zum Lehrplan, den T. Abdelzaher in einem Bericht über CPS-Ausbildung [412] 
veröffentlicht hat. 


Vorwort xi 


Verhalten, die Betriebs- und die Informationssicherheit sind zunehmend wichtiger 
geworden. Dadurch wurde es dadurch notwendig, eine dritte Auflage des engli- 
schen Originals zu publizieren. Die technischen Anderungen beeinflussten mehrere 
Kapitel sehr stark. In die Kapitel wurden solche Aspekte eingebetteter Systeme auf- 
genommen, die Grundlagen für den Entwurf von CPS- und IoT-Systemen bilden. In 
das Kapitel über Spezifikationen und Modellierung wurden partielle Differentialglei- 
chungen und Transaction-Level Modeling (TLM) aufgenommen. Die Verwendung 
dieses Buchs für das Konzept der Lehre mit vertauschten Rollen des Lernens zu 
Hause und in der Hochschule (Stichwort: flipped classroom) führte zur Betrachtung 
weiterer Details, v.a. im Bereich der Spezifikationen. Das Kapitel über Hardware 
wurde um Mehrkern-Systeme und mehr Informationen zur Umwandlung zwischen 
analogen und digitalen Signalen (einschließlich der Pulsbreitenmodulation) erweitert 
und der Abschnitt über Speicher umgeschrieben. Die Beschreibungen von Field Pro- 
grammable Gate Arrays (FPGAs) wurden erweitert und eine Einführung in Aspekte 
sicherer Hardware eingefügt. Das Kapitel über Systemsoftware wurde ergänzt durch 
einen Abschnitt über Linux in eingebetteten Systemen und mehr Informationen zu 
Zugriffsprotokollen auf Ressourcen. Im Kontext der Systembewertung wurden Un- 
terabschnitte über Qualitätsmetriken, Sicherheit, Energiemodelle und thermisches 
Verhalten eingefügt. Das Kapitel über die Abbildung von Anwendungen auf Aus- 
führungsplattformen wurde komplett restrukturiert: es wurde eine Klassifikation von 
Scheduling-Verfahren eingeführt und Scheduling-Verfahren für Mehrkern-Systeme 
hinzugefügt. Die Beschreibung des Hardware/Software-Codesigns wurde gestrichen. 
Das Kapitel über Optimierungen wurde aktualisiert und die Abbildungen wurden 
überarbeitet. Übungsaufgaben und eine klarere Unterscheidung zwischen Definitio- 
nen, Theoremen, Beweisen, Code und Beispielen wurden hinzugefügt. 

Aufgrund der zunehmenden Bedeutung des Zugriffs auf Wissen mit Hilfe des 
Internets wurde auf der Basis der dritten Auflage eine vierte Auflage im Rahmen 
einer Open Access-Lizenz erstellt. Damit werden die Inhalte des Lehrbuchs u.a. 
für Studierende kostenfrei verfügbar. Für die Publikation der vierten Auflage wur- 
den alle Kapitel wurden sorgfältig durchgesehen und ggf. aktualisiert. Fehler in der 
dritten Auflage wurden korrigiert. Die Beschreibung des springenden Balls wurde er- 
weitert. Die Darstellung von Daten- und Informationssicherheit wurde restrukturiert. 
Der Bezug zur Datenanalyse und zur künstlichen Intelligenz tritt nunmehr deutlicher 
hervor. Literaturhinweise wurden aktualisiert. Die Beschreibung der Begriffe Task, 
Prozess, Thread und Job wurde — soweit möglich — präzisiert. Aufgrund der Erwei- 
terungen ist es typischerweise nicht mehr möglich, das gesamte Buch in einem Kurs 
im Bachelorstudium zu behandeln. Vielmehr können Lehrkräfte eine Untermenge 
des Stoffes auswählen, die lokalen Anforderungen und Vorlieben entspricht. 

Aufgrund eines relativ großen Interesses an der deutschen Übersetzung der ersten 
englischen Auflage wurde die vorliegende deutsche Version der vierten englischen 
Ausgabe erstellt. Hierfür wurden teilweise Übersetzungen der ersten Auflage durch 
Lars Wehmeyer und der zweiten Auflage durch Michael Engel benutzt. Zur Vermei- 
dung sprachlich unschöner Mischungen werden deutsche Begriffe benutzt, soweit 
möglich. Dies machen wir sogar dann, wenn umgangssprachlich fremdsprachli- 
che Begriffe benutzt werden (Beispiele: Fließband statt pipeline, Verdrängung statt 
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preemption). Wenn deutsche Begriffe ungebräuchlich sind und passende fremd- 
sprachliche Begriffe bereits Teil der deutschen Sprache geworden sind, werden sie 
wie deutsche Worte gesetzt (Beispiele: Hardware, Software, Task, Job, Cache). Die 
Verwendung fremdsprachlicher Begriffe, die noch nicht Teil der deutschen Sprache 
geworden sind, ließ sich aber nicht vermeiden. Diese werden kursiv gesetzt. Sie 
werden groß geschrieben, wenn sie wie ein deutsches Substantiv benutzt werden 
(Beispiele: Schedule, Thread, Chip, Timer, Layout, Flash, Deadlock) oder wenn die 
Zusammensetzung einer Abkürzung klargemacht werden soll (Beispiel: Rate Mo- 
notonic (RM)). Sie werden klein geschrieben, wenn sie weiterhin als Fremdwort 
erscheinen (Beispiel: preemption). Soweit englische Begriffe mit Artikeln versehen 
werden müssen, werden diese wie bei den korrespondierenden deutschen Worten 
gewählt (Beispiele: die Task als zu die Aufgabe korrespondierend, der SPM als zu 
der ...-Speicher korrespondierend). 

Zur Kennzeichnung von Hervorhebungen wird ausschließlich Fettdruck genutzt. 
Zitate sind durch Anführungszeichen ausgewiesen. Namen, die in diesem Buch ohne 
Hinweis auf Urheberrechte benutzt werden, können dennoch rechtlich geschützt sein. 

Viel Spaß beim Lesen dieses Buchs! 


Dortmund, Peter Marwedel 
März 2021 
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Haufig benutzte mathematische Symbole 

Aufgrund des breiten Themenspektrums in diesem Buch könnte es leicht passie- 
ren, dass dasselbe Symbol für verschiedene Zwecke benutzt wird. Aus diesem Grund 
wurden die Symbole so gewählt, dass Verwechselungen vermieden werden können. 
Die nachfolgende Tabelle soll helfen, eine konsistente Notation zu verwenden. 
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Index, v.a. von Prozessoren 
Boltzmann-Konstante (~ 1,3807 * 107” J/K) 
Kelvin 
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Schlupf (engl. laxity) von Task/Job i 
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Index, v.a. von Zeiten 
Stoßzahl (engl. restitution) 
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Zustand 

Semaphor 
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Größe eines Speichers j 

Zeit (time) 

Transition i eines Petrinetzes 
Periode 

Periode von Task 7; 
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Auslastung (engl. utilization) 
Maximale Auslastung 
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Geschwindigkeit (engl. velocity) 
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Spannung (engl. voltage) 
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Operation auf einem Semaphor 

Volumen 

Signal 

Gewicht in einem Petrinetz 

Watt 

Eingabevariable 

Signal 

Entscheidungsvariablen 

Signal 

Entscheidungsvariablen 

Signal 

Zeitgeber 

Große Impedanz 

Ganze Zahlen 

Ankunftskurve im Realzeitkalkül 
Häufigkeit des Schaltens 
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In diesem Kapitel werden wir einige grundlegende Begriffe, die im Zusammenhang 
mit eingebetteten Systemen benutzt werden, zusammen mit der geschichtlichen Ent- 
wicklung vorstellen, sowie auf Möglichkeiten, Herausforderungen und gemeinsame 
Eigenschaften von eingebetteten und cyber-physikalischen Systemen eingehen. Au- 
ßerdem werden Aspekte der Ausbildung, Entwurfsabläufe und die Struktur dieses 
Buches vorgestellt werden. 


1.1 Geschichte der Begriffe 


Unter dem Begriff „Informationsverarbeitung” stellte man sich bis zum Ende der 
achtziger Jahre des letzten Jahrhunderts unweigerlich Großrechner und riesige Band- 
laufwerke vor. Die Miniaturisierung ermöglichte später die Einführung der Informa- 
tionsverarbeitung mit Hilfe von PCs (engl. Personal Computers). Büroanwendungen 
dominierten, aber einige Rechner wurden auch für Steuerungen und Regelungen 
innerhalb von Rückkopplungsschleifen in der physischen Umgebung eingesetzt. 
Später schuf Mark Weiser den Begriff des allgegenwärtigen Rechnens (engl. 
ubiquitous computing) [572]. Dieser Begriff bezieht sich auf Weisers Vorhersa- 
ge, künftig Rechner und Information überall und zu jeder Zeit zur Verfügung zu 
haben. Weiser sagte auch vorher, dass Rechner künftig in Produkte integriert wer- 
den würden, sodass sie unsichtbar werden würden. Daher schuf er den Begriff des 
unsichtbaren Computers. In ähnlicher Weise sorgte die vorhergesagte Durchdrin- 
gung unseres täglichen Lebens mit rechnenden Geräten zur Einführung der Begriffe 
durchdringendes Rechnen (engl. pervasive computing) und umgebende Intelli- 
genz (engl. ambient intelligence). Die drei Begriffe legen das Schwergewicht auf 
nur leicht unterschiedliche Aspekte künftiger Informationstechnologie. Der Begriff 
„allgegenwärtiges Rechnen” ist verbunden mit dem langfristigen Ziel, Informati- 
on jederzeit und überall bereitzustellen, wohingegen der Begriff „durchdringendes 
Rechnen” mehr mit den praktischen Aspekten und der Nutzung der bereits vor- 
handenen Technologie assoziiert wird. Der Begriff „umgebende Intelligenz” wird 
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in der Regel mit der Nutzung der Informationstechnologie in künftigen Wohnhäu- 
sern und intelligenten Bürogebäuden in Verbindung gebracht. Ein Teil der Visionen 
ist durch die Verbreitung von kleinen mobilen Geräten in Kombination mit dem 
mobilen Internet bereits Wirklichkeit geworden und diese Verbreitung ist durchaus 
„durchdringend” in dem Sinne, dass sie viele Bereiche des täglichen Lebens bereits 
beeinflusst hat. Von der ,,Kiinstlichen Intelligenz” wird ebenfalls ein großer Einfluss 
erwartet. 

Dabei wird häufig nicht bewusst wahrgenommen, dass die Miniaturisierung auch 
die Integration der Informationsverarbeitung mit der Umgebung vorangebracht hat. 
Ein derart integriertes informationsverarbeitendes System kann als eingebettetes 
System (ES) gemäß nachfolgender Definition bezeichnet werden. 


Definition 1.1 (Marwedel [372]): „Eingebettete Systeme sind informationsverar- 
beitende Systeme, die in umgebende Produkte integriert sind.” 


Beispielsweise finden wir eingebettete Systeme in Autos, Schienenfahrzeugen, 
Flugzeugen, der Telekommunikation und bei der Fertigungsautomatisierung. Ange- 
kündigte Produkte wie selbstfahrende Autos und Schienenfahrzeuge machen dabei 
klar, dass die Miniaturisierung bei eingebetteten Systemen ähnliche Veränderun- 
gen erwarten lässt wie die Verfügbarkeit von Mobilfunkgeräten. Für die genannten 
Beispiele gibt es dabei eine Vielzahl ähnlicher Anforderungen, wie u.a. ein vorher- 
sagbares Echtzeitverhalten, Verlässlichkeit und Effizienz. Für diese Systeme ist der 
Bezug zur Umgebung sehr wichtig. Dieser Bezug wird in dem nachfolgenden Zitat 
betont [330]: 

“Embedded software is software integrated with physical processes. The technical 
problem is managing time and concurrency in computational systems”. 

Obiges Zitat könnte als Definition des Begriff „eingebettete Software” benutzt 
werden und könnte zu einer Definition des Begriffs „eingebettete Systeme” verallge- 
meinert werden, indem wir einfach das Wort „Software” durch das Wort ,, System” 
ersetzen. 

Der starke Bezug zur realen Umgebung wurde noch mehr betont durch die Ein- 
führung des Begriffs „cyber-physikalisches System”. Dieser kann wie folgt definiert 
werden. 


Definition 1.2 (Lee [331]): ,,Cyber-physikalische Systeme (engl. Cyber-Physical 
Systems (CPS)) bestehen aus der Integration von Berechnungen und physikalischen 
Prozessen.” 


Eine Betonung der angesprochenen Integration ist sinnvoll, denn in einer Welt 
voller Anwendungen auf Servern, PCs und Mobilfunkgeräten wird sie häufig igno- 
riert. Für cyber-physikalische Systeme können wir erwarten, dass Modelle auch die 
Umgebung beschreiben. In diesem Sinne können wir uns vorstellen, dass cyber- 
physikalische Systeme eingebettete Systeme (d.h. den informationsverarbeitenden 
Teil) wie auch die (dynamische) physische Umgebung enthalten, oder CPS = ES 
+ (dynamisches) physisches bzw. physikalisches System. Dies spiegelt sich auch in 
Abb. 1.1 wider. 
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Abb. 1.1 Beziehung Cyber-physikalisches System (CPS) 
zwischen eingebetteten 
Systemen und physischer 
Umgebung 


(Eingebettetes System | Physische Umgebung ) 


In ihrem Aufruf für Projektvorschläge nennt die National Science Foundation 
(NSF) in den USA dabei auch die Verbindung (und damit die Kommunikation) ver- 
teilter Systeme (gemäß [413] in deutscher Übersetzung): „Die sich herausbildenden 
cyber-physikalischen Systeme werden koordiniert, verteilt und verbunden sein und 
sie müssen robust und reagierend sein.” 

Vernetzung (und damit die Kommunikation) wird auch im acatech-Bericht 
über CPS deutlich angesprochen (gemäß [6] in deutscher Übersetzung): Cyber- 
physikalische Systeme „stellen vernetzte, Software-intensive eingebettete Systeme 
in einer Regelschleife dar, die vernetzte und verteilte Dienste anbieten.” 

In einem Aufruf für Projektvorschläge der Europäischen Kommission [155] 
werden Verbindungen und Zusammenarbeit von Komponenten erwähnt: ,,Cyber- 
physikalische Systeme (CPS) beziehen sich auf die nächste Generation von IKT- 
Systemen, die verbunden und zusammenarbeitend sind — auch über das Internet 
der Dinge — und die Bürgern und Firmen einen breiten Bereich von neuartigen 
Anwendungen und Diensten anbieten.” 

Dabei hat die Europäische Kommission bereits früher die Bedeutung der Kom- 
munikation hervorgehoben, wie es in Abb. 1.2 zu sehen ist. 


Abb. 1.2 Bedeutung der 


Kommunikation Eingebettete 


Kommunikations- 


(© Europäische Kommission) technologie = aoa 
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- quality of service 
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Aus diesen Zitaten wird klar, dass die Autoren unter dem Begriff CPS nicht nur 
die Integration der Cyber- und der physischen Welt verstehen, sondern dass es auch 
einen starken Kommunikationsaspekt gibt. Tatsächlich wird der Begriff CPS nicht 
immer konsistent benutzt: einige Autoren betonen die Integration mit der physischen 
Umgebung, andere betonen die Kommunikation. 

Die Kommunikation wird noch expliziter in dem Begriff des „Internets der Dinge” 
(engl. Internet of Things (IoT)), der wie folgt definiert werden kann: 
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Definition 1.3 ([185]): Das Internet der Dinge „beschreibt die um sich greifende 
Gegenwart einer Vielfalt von Geräten — wie Sensoren, Aktuatoren und Mobilte- 
lefonen —, die mittels eindeutiger Adressierung in der Lage sind, miteinander zu 
interagieren und zu kooperieren, um gemeinsame Ziele zu erreichen.” 


Der Begriff verbindet die physische Umgebung mit dem Internet, um Sensoren- 
Information im Internet verfügbar zu machen und um Aktuatoren aus dem Internet 
heraus zu steuern. Es wird erwartet, dass das Internet der Dinge die Kommunikati- 
on zwischen Milliarden von Geräten erlauben wird. Diese Vision beeinflusst viele 
Industriezweige. 

Die Nutzung der IoI-Technologie für die Produktionstechnik ist als „Industrie 
4.0” [68] bezeichnet worden. Ziel ist eine flexiblere Produktion, bei welcher der 
gesamte Lebenszyklus durch diese Technologie unterstützt wird. 

Insgesamt bleibt es etwas dem Einzelnen überlassen, die Verbindung zwischen 
physischen Umgebungen und der Cyber-Welt als CPS oder als IoT zu bezeichnen. 
Wir können aber erwarten, dass CPS und IoT gemeinsam betrachtet den größten Teil 
der künftigen Anwendungen der Informationstechnologie ausmachen, insbesondere 
wenn wir die Systeme mit intelligenten Algorithmen ausstatten. 

Der Entwurf dieser künftigen Anwendungen setzt die Kenntnis der fundamen- 
talen Entwurfstechniken für eingebettete Systeme voraus. Dieses Buch behandelt 
genau diese fundamentalen Techniken, indem es allgemeine Schnittstellen zwischen 
den eingebetteten Systemen und der CPS-oder IoT-Umgebung vorstellt. Diese fun- 
damentalen Techniken werden beim Entwurf von CPS- und IoT-Systemen benötigt, 
auch wenn das nicht immer wieder in den einzelnen Kapiteln wiederholt wird. Für 
anwendungsspezifische Information sei jedoch auf spezialisiertere Quellen verwie- 
sen. 


1.2 Potential 


Die nachfolgende Liste verdeutlicht das riesige Potential für Anwendungen der In- 
formationsverarbeitung in CPS- und IoI-Systemen und sie gibt einen Eindruck von 
der Variationsbreite der verschiedenen Bereiche: 


« Transportwesen und Mobilität: 


— Automobilelektronik: Moderne Autos sind in technisch fortgeschrittenen 
Ländern nur verkäuflich, wenn sie über eine umfangreiche Ausstattung an 
elektronischen Komponenten verfügen [416]. Beispiele dafür sind Airbag- 
Steuergeräte, Motorsteuerungen, Navigationssysteme, Antiblockiersysteme 
(ABS), elektronische Stabilitätsprogramme (ESP), Klimaanlagen, Diebstahl- 
schutz, Fahrer-Assistenzsysteme und viele mehr. Ein Trend geht hin zu stärker 
autonom fahrenden Autos. Eingebettete Systeme können nicht nur den Kom- 
fort und die Sicherheit eines Autos verbessern, sie können potentiell auch dazu 
beitragen, die Umweltbelastung von Automobilen zu reduzieren. E-Mobilität 
ist ohne umfangreiche elektronische Ausstattung nicht vorstellbar. 
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— Luftfahrt: Ein nennenswerter Anteil der Gesamtkosten von Flugzeugen wird 
fiir informationsverarbeitende Systeme, wie z.B. Flugkontrollsysteme, Kolli- 
sionsvermeidungssysteme, Piloteninformationssysteme, Autopiloten usw. auf- 
gewendet. Die Verlässlichkeit ist von äußerster Wichtigkeit!. Eingebettete Sys- 
teme können die von Flugzeugen verursachten Emissionen (wie z.B. Kohlen- 
dioxid) reduzieren. Autonomes Fliegen wird auch mehr und mehr zu einer 
Realität, zumindest für spezielle Anwendungsbereiche. 

— Schienenverkehr: Die Lage im Eisenbahnbereich ist ähnlich der Situation 
bei Autos und Flugzeugen. Auch hier machen Sicherheitseinrichtungen einen 
beträchtlichen Anteil der Gesamtkosten aus und die Verlässlichkeit ist aus- 
gesprochen wichtig. Neue Signaltechniken zielen darauf, den Zugverkehr bei 
hohen Geschwindigkeiten und kurzen Abständen zwischen den Zügen zu si- 
chern. Das European Train Control System (ETCS) [444] ist ein Schritt in 
diese Richtung. Autonomer Schienenverkehr wird in begrenzten Kontexten 
(wie z.B. bei Shuttle-Ziigen auf Flughäfen) bereits eingesetzt. 

— Maritime Systeme und Schiffbau: CPS- und IoT-Systeme finden auch im 
Bereich moderner Schiffe und anderer maritimer Systeme Anwendung, z.B. für 
die Navigation, für Sicherheitskonzepte, für allgemeine Betriebsoptimierung 
und für die Dokumentation der Abläufe (siehe z.B. http://www.smtcsingapore. 
com/ und https://dupress.deloitte.com/dup-us-en/focus/internet-of-things/iot- 
in-shipping-industry.html). 

— Neue Mobilitätskonzepte: Der Einsatz von Informationstechnologie und de- 
ren Komponenten ermöglicht neue Mobilitätskonzepte. E-Bikes lassen auch 
ungeübte Personen größere Strecken per Fahrrad überwinden. Das subtile 
Wechselspiel zwischen menschlicher Muskelkraft und Kraft des Elektromo- 
tors macht E-Bikes zu einem Musterbeispiel für cyber-physikalische Systeme, 
ähnlich wie E-Roller. Das abendliche Einsammeln von E-Rollern anhand ei- 
ner Standortliste im Internet gibt dem Begriff „Internet der Dinge” eine be- 
sonders anschauliche Bedeutung. Auch bei neuen Sammelbus-, Mietwagen- 
und Fahrdienst-Konzepten sind CPS- und IoT-Techniken für eine Realisierung 
wichtig. 


e Maschinenbau (einschl. Fabrikautomatisation): Maschinen und Fertigungsanla- 
gen sind Bereiche, in denen eingebettete/cyber-physikalische Systeme traditionell 
schon seit Jahrzehnten zum Einsatz kommen. CPS- und IoI-Technologie kann ge- 
nutzt werden, um die Produktion weiter zu optimieren und sie ist ein Schlüssel zu 
einer flexibleren Produktion, die das Ziel der „Industrie 4.0”-Initiativen ist [68]. 
Die weitere Automatisierung wird durch die Logistik ermöglicht, die ihrerseits 
hierzu CPS- und IoT-Technologien einsetzt [298]. Es gibt viele Möglichkeiten, 
CPS- und IoT-Technologien in der Logistik einzusetzen. Beispielsweise erlaubt 
die Radio Frequency Identification (RFID)-Technologie die einfache Identifi- 
kation jedes Objektes, über Einbindung in ein Netz ggf. weltweit. Die mobile 
Kommunikation erlaubt eine nie gekannte Interaktion aller an einer Fertigung 
Beteiligten. 


! Das Beispiel der Boeing 737 MAX [420] macht die Gefahren sehr deutlich. 
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e Robotik: Die Robotik ist ein weiterer traditioneller Einsatzbereich für eingebet- 
tete/cyber-physikalische Systeme. Bei Robotern sind insbesondere die mechani- 
schen Aspekte von Interesse. Es wurden Roboter nach dem Vorbild von Menschen 
oder Tieren entwickelt. Abb. 1.3 zeigt einen solchen Roboter. 


Abb. 1.3 Humanoider Roboter ,,Lola” 
(mit Genehmigung durch D. Rixen, 
Lehrstuhl für Angewandte Mechanik, 
TU München), © TU München 


e Energieversorgung und das intelligente Netz: In der Zukunft wird die elek- 
trische Energieversorgung voraussichtlich sehr viel stärker dezentralisiert sein. 
Dies macht es schwer, die Stabilität der Stromversorgung sicherzustellen. Nur 
mit IKT-Systemen kann es gelingen, eine ausreichende Stabilität zu erreichen. 
Informationen zur intelligenten Versorgung mit elektrischer Energie können bei- 
spielsweise unter den Adressen https://www.smartgrid.gov/the_smart_grid und 
http://www.smartgrids.eu/ gefunden werden. 

e Bauingenieurwesen: CPS-Geräte können im Bauingenieurwesen eingesetzt wer- 
den. Beispielsweise kann die Statik von natürlichen und künstlichen Strukturen 
(z.B. von Bergen, Vulkanen, Brücken und Dämmen) überwacht werden. Die Abb. 
1.4 zeigt beispielsweise den Damm der Möhnetalsperre. Mit Hilfe von CPS- 
Technologie ist es möglich, bei Gefahren rechtzeitige Warnungen zu verbreiten?. 


e Intelligente Gebäude: Intelligente Gebäude sind einer der Bereiche des Bauin- 
genieurwesens. Informationsverarbeitung kann verwendet werden, um den Kom- 
fort in Gebäuden zu verbessern, den Energieverbrauch von Gebäuden zu senken 
und die Sicherheit zu erhöhen. Dafür müssen bisher nicht zusammenhängende 
Teilsysteme miteinander verbunden werden. Der Trend geht dahin, die Klima- 
steuerung, die Beleuchtung, die Zugangskontrolle sowie die Verwaltung und Ver- 
teilung von Informationen in ein einziges System zu integrieren. Damit können 


2 Der Dammbruch von Brumadinho (siehe https://de.wikipedia.org/wiki/Dammbruch_von_ 
Brumadinho) zeigt, wie es nicht ablaufen soll. 
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Abb. 1.4 Beispiel eines zu beobachtenden Dammes, des Möhnesee-Dammes ©P. Marwedel 


z.B. Klimaanlagen in leeren Räumen mit geringerer Leistung betrieben werden 
und gleichzeitig die Beleuchtung nur bei Bedarf aktiviert werden. Die durch die 
Klimatechnik erzeugten Geräusche können automatisch auf das notwendige Mi- 
nimum reduziert werden. Die intelligente Verwendung von Verdunkelungen kann 
zudem Beleuchtungs- und Klimaverhältnisse optimieren. Freie Räume können an 
zentralen Stellen im Gebäude angezeigt werden, damit können die Planung von 
kurzfristig anberaumten Besprechungen oder die Reinigung vereinfacht werden. 
In Notfallsituationen kann eine Liste von belegten Räumen am Gebäudeein- 
gang angezeigt werden (solange der Strom nicht ausgefallen ist). Durch diese 
Maßnahmen lässt sich Energie für Kühlung, Heizung und Beleuchtung einspa- 
ren und zudem kann die Sicherheit des Gebäudes verbessert werden. Anfangs 
werden solche Systeme nur in hochtechnisierten Bürogebäuden vorhanden sein. 
Ein Trend hin zu energieeffizienten Gebäuden ist aber auch beim Entwurf von 
Wohnhäusern zu erkennen. Eines der Ziele ist dabei der Entwurf sogenannter 
Niedrigenergiehäuser bzw. Nullenergiehäuser (Gebäude, die so viel Energie 
erzeugen, wie sie verbrauchen) [427]. Solche Gebäude könnten einen deutlichen 
Beitrag zur Verringerung der globalen Kohlendioxid-Emissionen und damit der 
globalen Erwärmung leisten. 

Agrartechnik: Es gibt viele I0T-Anwendungen in der Landwirtschaft, wie bei- 
spielsweise die Sicherstellung der Nachvollziehbarkeit des Lebensweges von 
Nutztieren. Im Fall des Ausbruchs ansteckender Krankheiten können so unmit- 
telbar Maßnahmen getroffen werden [516]?. Auch kann der Einsatz von Dünge- 
mitteln mittels IoT-Technologie dem Boden angepasst werden. 
Gesundheitswesen: Produkte des Gesundheitswesens gewinnen insbesondere 
durch die zunehmende Alterung der Bevölkerung an Bedeutung. Das Potential 
zur Innovation beginnt bei neuen Sensoren, die Krankheiten schneller und verläss- 
licher detektieren können. Neue Datenanalysetechniken können benutzt werden, 
um erhöhte Risiken zu erkennen und die Chancen auf Heilung zu verbessern. Da- 
für kommen i.d.R. auch neue Algorithmen zum Einsatz, beispielsweise solche der 


3 Die Bedeutung der Nachvollziehbarkeit von Kontakten im Allgemeinen, über die Tierzucht hinaus, 
wurde in der Corona-19-Krise besonders deutlich. 
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Künstlichen Intelligenz (KI). KI bietet auch die Möglichkeit einer personalisierten 
Medizin, um die Therapien durch angepasste Medikamente zu unterstützen. Neue 
Geräte können beispielsweise Behinderten helfen. Auch können Operationen ro- 
boterassistiert durchgeführt werden. CPS- und IoT-Technologien können dazu die- 
nen, Ergebnisse einer Therapie besser zu überwachen und damit Ärzten die Mög- 
lichkeit zu geben, die Wirksamkeit einer Behandlung zu überprüfen. Diese Über- 
wachung schließt auch entfernt lebende Patienten ein. Verfügbare Daten können 
in Patienteninformationssystemen gespeichert werden. Listen von Projekten in 
diesem Bereich können beispielsweise unter http://cps-vo.org/group/medical-cps 
und unter http://www.nano-tera.ch/program/health.html gefunden werden. 
Wissenschaftliche Experimente: Viele der gegenwärtigen wissenschaftlichen 
Experimente, insbesondere in der Physik, erfordern eine Erfassung der experi- 
mentellen Daten mit IKT-Geräten, d.h. der Cyber-Welt. Die Kombination von 
physikalischen Experimenten und der Cyber-Welt kann als Spezialfall cyber- 
physikalischer Systeme gesehen werden. 

Öffentliche Sicherheit: Das Interesse an Maßnahmen zur Steigerung der öffent- 
lichen Sicherheit wächst im Angesicht von Gewaltakten und Pandemien. CPS- 
und IoT-Systeme können die öffentliche Sicherheit stärken. Dies schließt die Er- 
kennung oder Authentisierung von Personen über verschiedene Sensoren ein. 
Katastrophenschutz: Im Fall größerer Katastrophen wie Erdbeben oder Über- 
flutungen ist es wesentlich, Leben zu retten und Überlebenden zu helfen. Hierzu 
sind flexible Kommunikationsstrukturen erforderlich. 

Militärische Anwendungen: Informationsverarbeitende Komponenten sind seit 
vielen Jahren ein wichtiger Bestandteil militärischer Systeme. Einige der aller- 
ersten Rechner wurden verwendet, um militärische Radarsignale zu analysieren. 
Sie sind auch heute wichtiger Teil von Abwehrsystemen. 

Telekommunikation: Die Mobiltelefonie ist einer der am stärksten wachsenden 
Märkte der vergangenen Jahre. Wichtige Aspekte von Mobiltelefonen sind der 
Entwurf der Funkkomponenten, die digitale Signalverarbeitung und ein niedriger 
Energieverbrauch. Telekommunikation ist auch ein wesentlicher Aspekt für IoT- 
Technologien. 

Unterhaltungselektronik: Video- und Audiosysteme sind ein wichtiger Bereich 
der Elektronikindustrie. Diese Geräte verwenden einen stetig ansteigenden Anteil 
an informationsverarbeitenden Komponenten. Neue Dienste und eine gesteiger- 
te Qualität werden dabei durch neuartige Methoden der digitalen Signalverar- 
beitung ermöglicht. Viele (vor allem hochauflösende) Fernseher, Smartphones 
und Spielkonsolen verwenden leistungsstarke Prozessoren und Speichersysteme. 
Diese stellen eine spezielle Klasse eingebetteter Systeme dar. Die Betriebssicher- 
heit und Realzeitbedingungen sind bei dieser Klasse nicht ganz so dringend zu 
berücksichtigen wie bei anderen Klassen. Allerdings sind teilweise auch Real- 
zeitbedingungen einzuhalten, beispielsweise um eine bestimmte Bildwiederhol- 
rate zu erreichen oder um Zeitbedingungen in Kommunikationsprotokollen zu 
garantieren. Auch sind Ressourcen wie die elektrische Energie oder die Kommu- 
nikationsbandbreite gerade bei mobilen Geräten extrem wichtig und damit liegt 
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hinsichtlich der Verfügbarkeit von Ressourcen eine Situation ähnlich der anderer 
eingebetteter Systeme vor. 


Die große Menge von Beispielen zeigt eindrucksvoll die große Vielfalt von ein- 
gebetteten Systemen, die in CPS oder IoT-Systemen eingesetzt werden. Weitere 
Anwendungen werden in einem Bericht zu den Möglichkeiten und den Herausfor- 
derungen des Internets der Dinge aufgeführt [516]. Wir gehen davon aus, dass viele 
der künftigen Anwendungen der IKT-Technologie sich in solchen Systemen finden 
werden. Aus obiger Liste schließen wir, dass praktisch alle Ingenieursdisziplinen 
betroffen sein werden. 

Die lange Liste der Anwendungen führt auch zu einer entsprechenden ökonomi- 
schen Bedeutung dieser Systeme. Laut acatech-Bericht [6] wurden zum Zeitpunkt 
der Berichterstellung 98% aller Mikroprozessoren in solchen Systemen eingesetzt. In 
gewisser Hinsicht sind eingebettete Systeme eine Voraussetzung für viele Produkte 
und sie haben einen Einfluss auf das Marktvolumen aller oben genannten Bereiche. 
Das gesamte Marktvolumen zu beziffern ist aber sehr schwer, denn es liegt deutlich 
über dem Marktvolumen der eingesetzten IKT-Komponenten. Es würde in die Irre 
führen, wenn man sich nur auf den Marktwert der Halbleiter beziehen würde, denn 
deren Wert macht nur einen Bruchteil des gesamten Wertes aus. 

Die ökonomische Bedeutung von CPS und IoT spiegelt sich wider in Aufrufen zur 
Einreichung von Projektvorschlägen von fördernden Institutionen, beispielsweise in 
den USA [116] und in Europa [156]. 
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Leider geht der Entwurf von eingebetteten Systemen und deren Integration in CPS- 
und IoI-Systeme einher mit einer großen Zahl von schwierigen Entwurfsaspekten, 
wie u.a. den nachfolgend aufgeführten: 


e Cyber-physikalische Systeme müssen verlässlich sein. 


Definition 1.4: Ein System ist verlässlich, wenn es den vorgesehenen Dienst mit 
hoher Wahrscheinlichkeit bereitstellt und keinen Schaden anrichtet. 


Verlässlichkeit ist erforderlich, weil diese Systeme mit der physischen Umgebung 
verbunden sind und einen direkten Einfluss auf diese Umgebung haben. Dieser 
Aspekt muss während des gesamten Entwurfsprozesses beachtet werden. 
Verlässlichkeit umfasst eine Reihe von Teilaspekten: 


1. Informationssicherheit (engl. security)*: Informationssicherheit hat den 
Schutz von Informationen als Ziel. Dabei können Informationen sowohl auf 
Papier, in Rechnern oder auch in Köpfen gespeichert sein. 


4 Im Deutschen werden die hier angeführten Begriffe ,,safety” und „security” meist beide durch 
das Wort „Sicherheit” wiedergegeben. Wir verwenden hier den Begriff „Informationssicherheit” 
für security und „Betriebssicherheit” für safery. 
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Definition 1.5 ([256, 75]): Die Informationssicherheit ist definiert als die Ge- 
währleistung von Vertraulichkeit, Integrität und Verfügbarkeit. 


Diese Gewährleistung kann durch Diebstahl oder Schäden aufgrund von An- 

griffen von außen gefährdet sein. Solche Angriffe können erfolgen, wenn CPS- 

oder IoT-Systeme mit der Umgebung verbunden werden. Cyber-Kriminalität 

und Cyber-Kriegsführung sind Beispiele solcher Angriffe mit einem Potential 

für erhebliche Schäden. Je mehr Komponenten man verbindet, umso mehr 

Angriffe und Schäden werden möglich. Dies ist zu einem schwerwiegenden 

Problem beim Entwurf und der Verbreitung von IoT-Systemen geworden. 

Die einzig sichere Lösung ist es, die Komponenten nicht mit der äußeren 

Umgebung zu verbinden, was aber der ursprünglichen Intention der Nutzung 

widerspricht. Zur Gewährleistung der Informationssicherheit sollen nach Ravi 

et al. [301] (mindestens) die folgenden Anforderungen erfüllt werden: 

— Ein Benutzer-Identifikationsprozess überprüft Identitäten, bevor Benut- 
zer ein System verwenden dürfen. 

— Ein sicherer Netzwerkzugang erlaubt eine Netzwerkverbindung nur dann, 
wenn das kommunizierende Gerät autorisiert ist. 

— Eine sichere Kommunikation erfüllt dafür notwendige Eigenschaften. 

— Eine sichere Speicherung verlangt Vertraulichkeit und Integrität der Daten. 

— Informationssicherheit der Inhalte verlangt Einschränkungen hinsicht- 
lich der Nutzung der Information. 


. Vertraulichkeit ist eine der Anforderungen an die Informationssicherheit. Sie 


kann wie folgt definiert werden: 


Definition 1.6 ([256, 75]): „Vertraulichkeit ist der Schutz vor unbefugter 
Preisgabe von Informationen. Vertrauliche Daten und Informationen dürfen 
ausschließlich Befugten in der zulässigen Weise zugänglich sein”. 


Vertraulichkeit wird üblicherweise mit Techniken zur Konstruktion informati- 
onssicherer Systeme hergestellt, z.B. durch Verschlüsselung. 


. Betriebssicherheit (engl. safety): 


Definition 1.7 ([251]): Betriebssicherheit kann definiert werden als „Abwe- 
senheit nicht annehmbarer Risiken einer physischen Verletzung oder eines 
Schadens der Gesundheit von Personen, weder direkt noch indirekt durch 
einen Schaden am Eigentum oder der Umgebung”. 

„Funktionelle Betriebssicherheit ist der Teil der gesamten Betriebssicherheit, 
die davon abhängt, dass ein System oder Gerät auf Eingaben korrekt reagiert”. 


„Im Kontext von Computersystemen wird der Begriff auch zur Abgrenzung 
von einer Sicherheit gegen äußere Angriffe, etwa durch Schadsoftware verwen- 
det. Betriebssicherheit bezieht sich dann im Unterschied dazu auf Gefahren 
durch Ausfälle, die ohne Fremdeinwirkung auftreten, also etwa Hardware- 
oder Stromausfälle, fehlerhaft geschriebene Software oder Bedienungsfehler” 
[574]. 
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4. Zuverlässigkeit: Dieser Begriff bezieht sich auf Fehlfunktionen von Systemen, 
die daraus resultieren, dass Komponenten nicht gemäß ihrer Spezifikation 
arbeiten, z.B. weil sie „kaputt” gehen. Zuverlässigkeit kann definiert werden 
als die Wahrscheinlichkeit, dass ein System den erwarteten Dienst für eine 
gewisse Zeitdauer erbringt® und sie kann als ein Aspekt der Betriebssicherheit 
gesehen werden. Im Rahmen der Beurteilung der Zuverlässigkeit betrachten 
wir keine Angriffe auf das System von außen, sondern nur Effekte, die im 
System während seines normalen Betriebs entstehen. 

5. Wartbarkeit: Die Wartbarkeit ist die Wahrscheinlichkeit, dass ein ausgefalle- 
nes System innerhalb einer bestimmten Zeitspanne repariert werden kann. 

6. Verfügbarkeit: Die Verfügbarkeit ist die Wahrscheinlichkeit, dass das Sys- 
tem verfügbar ist. Sowohl Zuverlässigkeit wie auch Wartbarbeit müssen hoch 
sein, um eine hohe Verfügbarkeit zu erzielen und damit zur Verlässlichkeit 
beizutragen. 


Entwickler eingebetteter Systeme könnten sich nun anfangs nur auf die Funk- 
tionalität eines Systems konzentrieren und versuchen, Verlässlichkeit zu einem 
funktionierenden Entwurf hinzuzufügen. Dieser Ansatz funktioniert in den meis- 
ten Fällen jedoch nicht, da bestimmte Entwurfsentscheidungen verhindern, dass 
beispielsweise die erforderliche Zuverlässigkeit im Nachhinein erreicht werden 
kann. Wenn die physikalische Aufteilung eines Systems falsch gewählt wurde, 
kann es unmöglich sein, ein redundantes System zu entwerfen. Daher darf „Zuver- 
lässigkeit nicht erst nachträglich zu einem System hinzugefügt werden”, vielmehr 
muss sie von Anfang an berücksichtigt werden [304]. Es müssen gute Kompro- 
misse gefunden werden, um ein ausreichendes Maß an Betriebssicherheit und 
Informationssicherheit zu finden [297]. 
Auch perfekt entworfene Systeme können ausfallen. Dies kann daran liegen, dass 
die zu Grunde liegenden Annahmen über die Auslastung und möglicherweise 
auftretende Fehler nicht korrekt waren [304]. So kann ein System beispielsweise 
ausfallen, wenn es außerhalb des ursprünglich angenommenen Temperaturbe- 
reichs betrieben wird. 

e Wenn wir uns die Schnittstelle zwischen der physischen und der Cyber-Welt 
genauer ansehen, stellen wir fest, dass physikalische und Cyber-Modelle nicht 
richtig zusammenpassen. Die nachfolgende Liste zeigt Beispiele: 


— Viele CPS-Systeme müssen Zeitschranken einhalten. Die Verletzung von Zeit- 
schranken kann zu einem ernsten Qualitätsverlust für bereitgestellte Dienste 
führen (wenn beispielsweise die Audio- oder die Videoqualität beeinträchtigt 
ist) oder dem Benutzer einen Schaden zufügen (wenn beispielsweise Autos, 
Eisenbahnen oder Flugzeuge nicht in der erwarteten Weise funktionieren). 
Einige Zeitschranken heißen harte Zeitschranken: 


Definition 1.8 (Kopetz [304]): Eine Zeitschranke heißt harte Zeitschranke, 
wenn ihr Nicht-Einhalten eine Katastrophe verursachen kann. Alle anderen 
Zeitschranken heißen weiche Zeitschranken. 


5 Eine formale Definition dieses Begriffs wird in Definition 5.36 auf Seite 307 gegeben. 


1 Einleitung 


Viele der aktuellen informationsverarbeitenden Systeme verwenden Techni- 
ken, um die durchschnittliche Geschwindigkeit der Informationsverarbeitung 
zu erhöhen. So verbessern beispielsweise Caches die durchschnittliche Leis- 
tung eines Systems. In anderen Fällen wird zuverlässige Kommunikation rea- 
lisiert, indem bestimmte Übertragungen wiederholt werden. Im Durchschnitt 
haben diese Wiederholungen nur einen (hoffentlich kleinen) Verlust an Über- 
tragungsleistung zur Folge, auch wenn die Kommunikationsverzögerung für 
eine bestimmte Nachricht einige Größenordnungen über der normalen Ver- 
zögerung liegen kann. Im Kontext von Echtzeitsystemen sind Diskussionen 
über durchschnittliche Leistung oder Verzögerung eines Systems aber nicht 
akzeptabel. „Eine garantierte Systemantwort muss ohne Verwendung sta- 
tistischer Argumente erklärt werden können” [304]. 

Viele Modellierungstechniken der Informatik benutzen keine echte Zeit. Häu- 
fig wird die Zeit ohne Benutzung physikalischer Einheiten modelliert, womit 
keine Unterscheidung zwischen Picosekunden und Jahrhunderten gemacht 
wird. Die resultierenden Probleme wurden von Edward Lee sehr klar benannt: 
„Das Fehlen der Zeit in Kernmodellen (der Informatik) ist aus Sicht der Soft- 
ware eingebetteter Systeme ein Fehler” [333]. 

Viele eingebettete Systeme sind hybride Systeme, sie beinhalten analoge und 
digitale Bestandteile. Analoge Komponenten verwenden kontinuierliche Si- 
gnale über einem kontinuierlichen Zeitbereich, wogegen digitale Komponen- 
ten diskrete Signalwerte über einem diskreten Zeitbereich verwenden. Viele 
physikalische Einheiten werden von einem Paar dargestellt, bestehend aus einer 
reellen Zahl und einer Einheit. Die Menge der reellen Zahlen ist überabzählbar. 
In der Cyber-Welt ist die Menge der darstellbaren Werte endlich. Daher kön- 
nen fast alle physikalischen Größen auf Computern nur approximiert werden. 
Bei der Simulation von physikalischen Systemen auf Computern nehmen wir 
üblicherweise an, dass uns diese Approximation sinnvolle Ergebnisse liefert. 
Taha [522] hat die Konsequenzen der Nicht-Verfügbarkeit von reellen Zahlen 
in der Cyber-Welt beschrieben. 

Physikalische Systeme können den sogenannten Zeno-Effekt aufweisen. Der 
Zeno-Effekt kann anhand des Beispiels des springenden Balls eingeführt wer- 
den. Angenommen, wir lassen einen Ball von einer bestimmten Höhe auf den 
Boden fallen. Nachdem wir den Ball loslassen, wird er beginnen zu fallen und 
dabei durch die Erdbeschleunigung beschleunigt werden. Wenn er auf dem 
Boden auftrifft, wird er aufgrund der Annahme eines teilweise elastischen 
Verhaltens reflektiert werden, d.h. er bewegt sich in die umgekehrte Rich- 
tung. Wir nehmen an, dass die Reflexion eine bestimmte Dämpfung besitzt 
und dass der Betrag der Geschwindigkeit unmittelbar nach der Reflexion ge- 
genüber der Geschwindigkeit unmittelbar vor der Reflexion um einen Faktor 
s reduziert ist. Aufgrund dieser Annahme sprechen wir von einem teilelasti- 
schen Stoß. s heißt Stoßzahl. Aufgrund der Dämpfung wird der Ball nach 
dem Stoß nicht wieder die anfängliche Höhe erreichen. Außerdem wird die 
Zeit bis zum zweiten Aufprallen auf dem Boden kürzer sein als beim ersten 
Mal. Dieser Vorgang wird sich wiederholen, mit kürzeren und kürzeren Ab- 
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ständen zwischen den Stößen. Aufgrund des idealen Modells teilelastischer 
Stöße wird sich dieser Vorgang aber immer wiederholen. Abb. 1.5 zeigt ein 
Weg-Zeit-Diagramm (die Höhe als Funktion der Zeit) des teilelastischen Balls. 
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Abb. 1.5 Weg-Zeit-Diagramm eines teilelastischen Balls (© Openmodelica) 


Sei nun A ein beliebiges Zeitintervall mit einem beliebigen Anfangszeitpunkt. 
Gibt es eine obere Schranke für die Anzahl der Stöße in diesem Zeitintervall? 
Nein, eine solche Schranke gibt es nicht, denn im idealen Modell ereignen sich 
die Stöße immer wieder, aber die Zeitabstände werden immer kürzer. Dies ist 
ein spezieller Fall des Zeno-Effekts. Ein System zeigt einen Zeno-Effekt, wenn 
es möglich ist, eine unbegrenzte Anzahl von Ereignissen in einem Intervall von 
endlicher Länge zu haben [404]. Mathematisch gesehen ist das möglich, denn 
eine unendliche Reihe kann zu einem endlichen Wert konvergieren. In diesem 
Fall konvergiert die unendliche Zeitreihe der Zeitpunkte der Reflexionen zu 
einer endlichen Zeit. In Digitalrechnern können wir eine unbegrenzte Zahl von 
Ereignissen nur approximieren. Weitere Details zu diesem Beispiel werden ab 
Seite 50 diskutiert werden. Wichtig ist, dass wir in einem Digitalrechner eine 
unbegrenzte Zahl von Ereignissen nur approximieren können. 
— Viele eingebettete Systeme enthalten Regelschleifen wie in Abb. 1.6. 


Regelstrecke 

Periodische Abtastun 
- a ae 
Rückkopplung 


Abb. 1.6 Regelschleife 
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Die Theorie von Regelschleifen basierte urspriinglich auf analogen, zeitkonti- 
nuierlichen Riickkopplungen. Fiir digitale, zeitdiskrete Rtickkopplungen wurde 
standardmäßig über Jahrzehnte hinweg eine periodische Abtastung eingesetzt 
und diese funktionierte hinreichend. Dennoch ist die periodische Abtastung 
nicht der bestmögliche Weg. Wir können Ressourcen einsparen, indem wir die 
Abtastintervalle in Zeiten relativ konstanter Signale vergrößern. Dies ist die 
Idee der adaptiven Abtastung. Adaptive Abtastung ist Gegenstand aktiver 
Forschung [210]. 

— Traditionelle sequentielle Programmiersprachen sind nicht der beste Weg, 
nebenläufige, zeitbehaftete Systeme zu beschreiben. 

— Traditionellerweise liefert die Überprüfung einer korrekten Implementierung 
einer Spezifikation ein Boolesches Ergebnis: entweder ist die Implementierung 
korrekt oder nicht. Allerdings sind zwei physikalisch vorhandene Implemen- 
tierungen nie exakt identisch, sie könnten beispielsweise in ihren Abmessun- 
gen geringfügig voneinander abweichen. Dies führt zu einer Unschärfe in 
der Beurteilung und die Boolesche Verifikation müsste durch eine unscharfe 
Verifikation (engl. fuzzy verification) ersetzt werden [446, 184]. 

— Nach Edward Lee [332] kann die Kombination eines deterministischen physi- 
kalischen Modells und eines deterministischen Cyber-Modells möglicherwei- 
se ein nicht-deterministisches Modell sein. Nicht-deterministische Abtastung 
kann dafür eine Ursache sein. 


Insgesamt beobachten wir eine Diskrepanz zwischen der physischen und der 
Cyber-Welt. Dementsprechend suchen wir nach geeigneten Modellen für cyber- 
physikalische Systeme, aber wir können nicht erwarten, dass wir diese Diskrepanz 
vollkommen beseitigen können. 

Eingebettete Systeme müssen effizient mit Ressourcen umgehen. Dazu müssen 
wir uns der verwendeten Ressourcen gewahr sein. Die folgenden Metriken können 
verwendet werden, um die Effizienz eingebetteter Systeme zu bewerten: 


1. Energie: Die elektronische Datenverarbeitung (EDV) benötigt, wie der Name 

es erwarten lässt, für die Verarbeitung von Daten elektrische Energie. Die 
Menge der benötigten Energie wird häufig „verbrauchte Energie” genannt. 
Streng genommen ist das falsch, denn die Energie bleibt insgesamt erhalten. 
Tatsächlich wandeln wir (nur) elektrische Energie in eine andere Form der 
Energie, üblicherweise in thermische Energie. Für eingebettete Systeme ist die 
Verfügbarkeit elektrischer Leistung und Energie (als Integral der Leistung 
über der Zeit) ein entscheidender Faktor. Dies wurde bereits im Rahmen ei- 
ner niederländischen Technologievorhersage bemerkt: „(elektrische) Leistung 
wird als die wichtigste Randbedingung bei eingebetteten Systemen betrachtet” 
[150]. 
Warum sollten wir uns der Menge der umgewandelten Energie gewahr sein, 
d.h. uns um diese Menge kümmern (und sie auch so sparsam wie möglich 
einsetzen)? Dafür gibt es viele Gründe, ein großer Teil davon ist für alle 
Systemklassen anwendbar, aber es gibt auch weniger relevante Kombinationen 
von Gründen und Systemklassen, wie in Tabelle 1.1 zu sehen ist. 
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Tabelle 1.1 Abhängigkeit der Relevanz von Energieeinsparungsgriinden von der Systemklasse 


Während der Nutzung relevant? 
Systemklasse Netzbetrieb | Akkubetrieb ohne Netz 
Beispiel Fabrik Laptop Sensor-Netzwerk 
Globale Erwärmung ja kaum nein 
Kosten der Energie ja kaum üblicherweise nicht 
Höhere Performanz ja ja ja 
Laufzeit ohne Netz nein ja ja 
Thermische Effekte, Überhitzung ja ja ja 
Vermeiden hoher Ströme, Metallwanderung ja ja ja 
Kaum Energie vorhanden nein selten ja 


Die globale Erwärmung ist natürlich ein sehr wichtiger Grund, um des Ver- 
brauchs an elektrischer Energie gewahr zu sein. Allerdings ist die Menge an 
verfügbarer Energie bei mobilen Systemen üblicherweise sehr klein und daher 
ist der Beitrag dieser Systeme zur globalen Erwärmung ebenfalls kleins. 

Die Kosten der Energie sind relevant, wenn die benötigte Menge an Energie 
teuer ist. Bei Systemen mit Netzbetrieb kann dies aufgrund großer Mengen 
an Energie passieren. Für Systeme ohne Netzbetrieb sind diese Mengen meist 
klein, aber es kann Fälle geben, in denen selbst kleine Mengen teuer sind. 
Eine größere Performanz (Rechenleistung) verlangt - sofern nicht Fortschritte 
in der Technologie diese ermöglichen - i.d.R. nach mehr Energie. 

Die Laufzeit ohne Stromnetz ist z.B. für Mobiltelefone und Laptops relevant. 
Thermische Effekte werden wichtiger, weil zu heiße Systeme nicht benutzbar 
sind und weil die Zuverlässigkeit von Systemen mit steigenden Temperaturen 
sinkt. Es kann sogar notwendig sein, Teile von Silizium-Chips abzuschalten, 
d.h. von der Stromversorgung zu trennen, um eine Überhitzung zu vermeiden. 
Diese Notwendigkeit ist unter dem Begriff dark silicon bekannt geworden 
[153]. Daher müssen thermische Effekte ebenfalls betrachtet werden. 

Hohe Stromdichten können dazu führen, dass Metalle in Chips sich nicht mehr 
wie Festkörper verhalten, sondern wandern. 

In einigen Fällen, wie z.B. räumlich entfernt aufgestellten Sensorknoten, ist 
Energie eine wirklich sehr knappe Ressource. 

Es ist interessant anzusehen, in welchen Fällen ein Grund für effiziente Nut- 
zung der Energie nicht so relevant ist. Bei Systemen, die mit dem Stromnetz 
verbunden sind, ist Energie i.d.R. keine knappe Ressource. Bei Systemen, 
die nicht mit dem Stromnetz verbunden sind, ist der Einfluss auf die globale 
Erwärmung gering, weil die Kapazität von Stromspeichern begrenzt ist. 


6 Dies sei durch ein konkretes Zahlenbeispiel belegt: ein derzeit als groß empfundener Akku 
eines Mobiltelefons hätte beispielsweise eine Kapazität von 3600 mAh und für die Spannung 
nehmen wir eine mittlere Spannung von 4V an. Damit ergibt sich eine Energie von 14,4 Wh. 
Eine vollständige Ladung entspricht damit dem Verbrauch eines i.d.R. permanent eingeschalteten 
Internet-Zugangsknotens in ca. 1-2,5 Stunden bzw. eines Fernsehgerätes im Bruchteil einer Stunde. 
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Die Bedeutung der Energie- und Leistungseffizienz wurde zunächst bei ein- 
gebetteten Systemen wahrgenommen und wurde später für allgemeine Rech- 
neranwendungen zur Kenntnis genommen. Die Bedeutung der Energieeffizienz 
führte zu Initiativen wie der green computing initiative [11]. 

Allgemein sollte nicht vergessen werden, dass es nicht nur auf den Energiever- 
brauch während des Betriebes ankommt. Vielmehr hat auch die Herstellung 
von Systemen einen erheblichen Anteil am Energieverbrauch. Es sollte da- 
her der komplette Lebenszyklus eines Produktes im Rahmen eines Life Cycle 
Assessments (LCA) bewertet werden [375]. Dementsprechend kann man den 
Einfluss auf die Umwelt reduzieren, indem man seltener ein neues Gerät kauft. 


. Laufzeit-Effizienz: Eingebettete Systeme sollten die verfügbare Hardwarear- 


chitektur so gut wie möglich ausnutzen. Eine ineffiziente Nutzung von Aus- 
führungszeit (z.B. verschwendete Prozessorzyklen) sollte vermieden werden. 
Dies impliziert eine Optimierung der Ausführungszeiten über alle Ebenen 
hinweg, von den Algorithmen bis zu Hardwareimplementierungen. 


. Codegröße: Bei manchen eingebetteten Systemen muss der Code für die 


Ausführung von Software in dem System selbst gespeichert werden. Hierfür 
kann es aber sehr strenge Randbedingungen geben. Dies gilt insbesondere für 
Systems on a Chip (SoCs), d.h. Systeme, bei denen die gesamte Informations- 
verarbeitung auf einem Chip integriert ist. Wenn auch der Speicher mit auf 
diesem Chip integriert ist, muss er sehr effizient genutzt werden. Beispielswei- 
se kann es medizinische Geräte geben, die im menschlichen Körper implantiert 
werden. Aufgrund der Beschränkungen der Größe und der Kommunikations- 
möglichkeiten müssen diese Geräte sehr kompakt sein. 

Allerdings kann sich die Bedeutung dieser Einschränkung ändern, wenn das 
dynamische Laden von Code akzeptabel wird oder wenn größere Speicherdich- 
ten (gemessen in Bits pro Volumeneinheit) verfügbar werden. Flash-Speicher 
und neue Speichertechnologien können potentiell einen großen Einfluss haben. 


. Gewicht: Tragbare Systeme dürfen nicht schwer sein. Ein geringes Gewicht 


ist oft ein wichtiges Argument für den Kauf eines bestimmten Gerätes. 


. Kosten: Eingebettete Systeme für den Massenmarkt, wie Konsumelektronik, 


werden in hohen Stückzahlen hergestellt. Bei diesen Geräten ist die Wettbe- 
werbsfähigkeit besonders wichtig und daher ist eine effiziente Nutzung der 
Hardwarekomponenten und des Budgets für Softwareentwicklung erforder- 
lich. Zur Implementierung der benötigten Funktionalität sollte eine minimale 
Menge an Ressourcen verwendet werden. Wir sollten also die Anforderun- 
gen mit der geringsten Menge an Hardwareressourcen und Energie erfüllen 
können. Um den Energieverbrauch zu reduzieren, sollten Taktfrequenzen und 
Versorgungsspannungen so gering wie möglich sein. Zudem sollten nur die 
unbedingt notwendigen Hardwarekomponenten vorhanden sein. Komponen- 
ten, welche die maximale Ausführungszeit (engl. Worst Case Execution Time 
(WCET)) nicht verbessern (wie z.B. viele Caches oder virtuelle Speicherver- 
waltungseinheiten), können in manchen Fällen weggelassen werden. 
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Um geforderte Effizienzkriterien zu erfiillen, kann der Softwareentwurf nicht un- 
abhängig von der darunterliegenden Hardware erfolgen. Daher müssen in allen 
Entwurfsschritten sowohl die Software wie auch die Hardware beriicksichtigt 
werden. Dies ist jedoch schwierig, da solche integrierten Ansätze normalerweise 
nicht gelehrt werden. Die Zusammenarbeit zwischen Elektrotechnik und Infor- 
matik hat den dafür erforderlichen Umfang noch nicht erreicht. 

Die beste Energieeffizienz würde bei einer Abbildung der Spezifikationen auf 
Hardware erzielt werden. Hardwareimplementierungen sind aber sehr teuer und 
erfordern eine lange Entwurfsdauer. Daher bieten Hardwareentwürfe nicht die 
benötigte Flexibilität, um Entwürfe bei Bedarf anzupassen. Wir benötigen also 
einen guten Kompromiss zwischen Effizienz und Flexibilität. 

e CPS- und IoT-Systeme sammeln sehr häufig große Mengen an Daten. Diese Daten 
müssen gespeichert werden und sie müssen analysiert werden. Daher gibt es eine 
starke Verbindung zwischen der Datenanalyse bzw. Maschinellem Lernen und 
CPS/IoT. Dies ist genau der Gegenstand unseres Sonderforschungsbereichs SFB 
8767. Der SFB 876 hat seinen Schwerpunkt beim Maschinellen Lernen unter 
Ressourcen-Beschränkungen. 

« Einfluss jenseits technischer Fragen: Aufgrund des großen Einflusses auf die 
Gesellschaft müssen auch rechtliche, ökonomische, soziale, menschliche und 
umwelttechnische Folgen betrachten werden: 


— Die Integration vieler Komponenten, möglicherweise von verschiedenen Her- 
stellern, lässt die Frage nach der Haftung aufkommen. Diese Frage wird bei- 
spielsweise für autonom fahrende Autos diskutiert. Auch muss geklärt werden, 
wer welche Rechte hat. Es kann nicht akzeptiert werden, dass alle Rechte einer 
Firma gehören. 

— Die sozialen Folgen der neuen IKT-Geräte müssen auch bedacht werden. Dies 
hat zur Einführung des Begriffs des Cyber Physical Social Systems (CPSS) 
geführt [140]. Gegenwärtig werden diese Folgen häufig erst lange nach der 
Verfügbarkeit der Geräte bemerkt, wie das beispielsweise bei Mobiltelefonen 
der Fall ist. 

— Benutzerfreundliche Mensch-Maschine-Schnittstellen müssen verfügbar sein, 
um nicht größere Teile der Gesellschaft von der Anwendung auszuschließen. 

— Der Beitrag zur globalen Erwärmung und der entstehende Abfall sollte mög- 
lichst gering sein und einen akzeptablen Umfang nicht übersteigen. Dasselbe 
gilt für den Ressourcen-Verbrauch. 


e Reale Echtzeitsysteme sind hochgradig nebenläufig (engl. concurrent). Die Ver- 
waltung der Nebenläufigkeit ist eine weitere große Herausforderung. 

e CPS- und IoT-Systeme bestehen typischerweise aus heterogenen Hard- und Soft- 
warekomponenten von verschiedenen Herstellern und sie müssen in einer sich 
verändernden Umgebung funktionieren. Die Heterogenität führt zu Herausforde- 
rungen für die korrekte Kooperation der verschiedenen Komponenten. Es ist nicht 
ausreichend, nur den Software- oder den Hardwareentwurf zu betrachten. Auf- 


7 Siehe http://www.sfb876.tu-dortmund.de. 
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grund der Entwurfskomplexität muss ein hierarchischer Ansatz gewählt werden. 
Reale eingebettete Systeme bestehen aus vielen Komponenten und wir interes- 
sieren uns daher für den kompositionellen Entwurf. Das bedeutet, wir möchten 
die Folgen der Integration von Komponenten analysieren [214]. Beispielsweise 
möchten wir wissen, ob wir ein Navigationssystem zu den Informationsquellen 
im Auto hinzufügen können, ohne den Kommunikationsbus zu überlasten. 

e Der Entwurf von CPS-Systemen erfordert Wissen aus vielen Gebieten. Es ist 
schwierig, Mitarbeiter zu finden, die in allen relevanten Bereichen ein ausrei- 
chendes Wissen haben und schon der Austausch von Wissen zwischen diesen 
Bereichen ist eine Herausforderung. Eine noch größere Herausforderung ist es, 
ein Ausbildungsprogramm für den Entwurf von CPS-Systemen zu entwickeln, 
da es enge Obergrenzen für den studentischen Arbeitsaufwand gibt [379]. Insge- 
samt wäre es erforderlich, die Wände zwischen den Disziplinen und Fakultäten 
niederzureißen, oder sie zumindest niedriger zu gestalten. 


Eine Liste der Herausforderungen findet sich auch im Bericht über IoT von Sund- 
maeker et al. [516]. 


1.4 Gemeinsame Eigenschaften 


Zusätzlich zu den aufgeführten Herausforderungen gibt es weitere gemeinsame Ei- 
genschaften von eingebetteten, cyber-physikalischen und IoT-Systemen, unabhängig 
vom Anwendungsbereich. 


e Diese Systeme werden oft durch Sensoren, die Informationen über diese Umge- 
bung sammeln, und Aktuatoren, welche die Umgebung steuern, mit der physi- 
schen Umgebung verbunden. Beim Internet der Dinge werden diese Komponenten 
mit dem Internet verbunden. 


Definition 1.9: Aktuatoren sind Komponenten, die numerische Werte in physi- 
kalische Effekte verwandeln. 


e Üblicherweise sind eingebettete Systeme reaktive Systeme, die wie folgt definiert 
werden können: 


Definition 1.10 (Berge [566]): „Ein reaktives System ist ein System, das sich in 
ständiger Interaktion mit seiner Umgebung befindet und mit einer Geschwindig- 
keit reagiert, die durch diese Umgebung vorgegeben wird.” 


Reaktive Systeme modellieren wir als Systeme, die sich in einem Zustand befinden 
und auf eine Eingabe warten. Für jede Eingabe wird eine bestimmte Berechnung 
durchgeführt und eine Ausgabe sowie ein neuer Zustand erzeugt. Daher stellen 
endliche Automaten sehr gute Modelle für solche Systeme dar. Mathematische 
Funktionen zur Beschreibung der von Algorithmen zu lösenden Probleme wären 
hier ein unpassendes Modell. 
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e Eingebettete Systeme sind in der Lehre und in der öffentlichen Diskussion 
unterreprasentiert. Reale eingebettete Systeme sind komplex. Daher wird eine 
umfangreiche Ausstattung benötigt, um das Thema realistisch zu unterrichten. 
Allerdings kann die Lehre des CPS-Entwurfs aufgrund des sichtbaren Einflusses 
auf das physische Verhalten auch attraktiv sein. 

e Diese Systeme sind meist für eine bestimmte Anwendung ausgelegt. Prozes- 
soren, die Steuerungssoftware in einem Auto oder einem Zug ausführen, werden 
i.d.R. nur diese Software ausführen. Es wird niemand versuchen, ein Computer- 
spiel oder eine Tabellenkalkulation auf diesen Prozessoren auszuführen. Dafür 
gibt es hauptsächlich zwei Gründe: 


1. Die Ausführung zusätzlicher Programme würde diese Systeme weniger ver- 
lässlich machen. 

2. Die Ausführung zusätzlicher Programme ist nur möglich, wenn es ungenutzte 
Ressourcen, wie z.B. Speicher, gibt. In einem effizienten System sollten aber 
keine ungenutzten Ressourcen vorkommen. 


Allerdings ändert sich die Situation langsam. Beispielsweise zeigt die AUTOSAR- 
Initiative mehr Dynamik in der Automobilindustrie [27]. 

e Die meisten eingebetteten Systeme verwenden weder Tastaturen, Mäuse noch 
große Bildschirme für ihre Benutzerschnittstellen. Stattdessen existiert eine de- 
dizierte Benutzerschnittstelle, bestehend aus Schaltern, Lenkrädern, Pedalen 
usw. Daher nimmt der Benutzer meist nicht wahr, dass in solchen Systemen Infor- 
mationen verarbeitet werden. Aus diesem Grund wird diese neue Ära der Rechner 
auch als Ära des verschwindenden Rechners bezeichnet. 


Die Tabelle in 1.2 stellt einige herausragende Unterschiede zwischen dem Entwurf 
PC-ähnlicher Systeme und dem Entwurf eingebetteter Systeme dar, die bei der 
Abbildung von Anwendungen auf Hardwareplattformen relevant sind. 


Tabelle 1.2 Unterschiede zwischen PC/Server-ähnlichen und eingebetteten Systemen 


Eingebettet PC/Server-ähnlich 
Architekturen Häufig heterogen, Meist homogen, 

sehr kompakt nicht kompakt (x86 usw.) 
x86-Kompatibilität Weniger wichtig Sehr wichtig 
Festgelegte Architektur? |Selten Ja 


Berechnungs- C+div. Modelle (Datenfluss, Meist von Neumann 

modell (MoC) diskrete Ereignisse, ...) (C, C++, Java) 

Optimerungsziele Mehrere (Energie, Größe, ...) Durchschnittliche Performanz 
überwiegt 

Sicherheitskritisch? Möglicherweise Kaum 

Echtzeitsystem? Häufig Selten 


Anwendungen zur Ent- 
wurfszeit bekannt 


Die meisten oder alle 


Nur einige (z.B. WORD) 
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Die Kompatibilität mit von x86-PCs her bekannten Befehlssätzen ist für einge- 
bettete Systeme weniger wichtig, da es normalerweise möglich ist, Softwareanwen- 
dungen für eine gegebene Architektur neu zu übersetzen. Sequenzielle Program- 
miersprachen eignen sich nicht gut für die Aufgabe, nebenläufige Echtzeitsysteme 
zu beschreiben. Hier könnten andere Ansätze zur Modellierung von Anwendungen 
vorteilhafter sein. Während des Entwurfs eingebetteter/cyber-physikalischer Syste- 
me müssen verschiedene Ziele berücksichtigt werden. Außer der durchschnittlichen 
Rechenleistung (Performanz) sind hier die größtmögliche Ausführungszeit (WCET), 
der Energieverbrauch, das Gewicht, die Zuverlässigkeit, die Betriebstemperaturen 
usw. mögliche Optimierungsziele. Das Einhalten von Echtzeitbedingungen ist für 
cyber-physikalische Systeme sehr wichtig, aber nur selten für PC-Systeme. Das Ein- 
halten von Zeitbedingungen kann nur dann zur Entwurfszeit verifiziert werden, wenn 
alle Anwendungen auch zur Entwurfszeit bekannt sind. Zudem muss bekannt sein, 
welche Anwendungen gleichzeitig ablaufen sollen. So müssen Entwickler beispiels- 
weise sicherstellen, dass eine GPS-Anwendung, ein Telefonanruf und Datenüber- 
tragungen gleichzeitig stattfinden können, ohne dass Sprachinformationen verloren 
gehen. Bei PC-Systemen ist ein solches Wissen so gut wie nie verfügbar und man 
arbeitet mit best effort-Ansätzen, d.h. man versucht, Software möglichst schnell 
ablaufen zu lassen, ohne ein bestimmtes Verhalten zu garantieren. 

Warum versuchen wir, alle verschiedenen Arten eingebetteter Systeme in einem 
Buch zu behandeln? Der Grund dafür ist, dass die informationsverarbeitenden Kom- 
ponenten in all diesen Systemen über viele gemeinsame Eigenschaften verfügen, 
auch wenn die Systeme selbst physisch sehr unterschiedlich sind. 

Nicht jedes eingebettete System wird über alle der oben genannten Eigenschaften 
verfügen. Wir können den Begriff „eingebettetes System” auch wie folgt definieren: 


Definition 1.11: Informationsverarbeitende Systeme, welche die meisten der oben 
genannten Eigenschaften erfüllen, werden eingebettete Systeme genannt. 


Diese Definition beinhaltet eine gewisse Unschärfe. Es scheint aber weder not- 
wendig noch möglich, diese Unschärfe zu beseitigen. 


1.5 Lehrplan-Integration von Eingebetteten Systemen, CPS und 
IoT 


Leider werden eingebettete Systeme im Computer Science Curriculum, veröffent- 
licht im Jahr 2013 von ACM und der IEEE Computer Society [10], so gut wie nicht 
berücksichtigt. Die wachsende Bedeutung eingebetteter Systeme führt aber zu einem 
gesteigerten Bedarf an Ausbildung in diesem Bereich. Diese Ausbildung soll dabei 
helfen, die Beschränkungen aktuell verfügbarer Entwurfsmethoden zu überwinden. 
Eine Übersicht über Anforderungen und Ansätze zur Lehre im Bereich CPS wurden 
von den National Academies of Sciences, Engineering and Medicine [410] sowie 
von Marwedel et al. [379] sowie publiziert. Es gibt beispielsweise Bedarf an besse- 
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ren CPS-Modellen, Spezifikationssprachen, Entwurfstechniken für unterschiedliche 
Zielkriterien, Synthese- und Verifikationswerkzeugen, Echtzeitbetriebssystemen so- 
wie anderer Systemsoftware. Dieses Buch soll helfen, wesentliche Fragestellungen 
zu vermitteln und ein Sprungbrett für weitere Forschung in diesem Gebiet sein. 
Zusätzliche Informationen zum Buch gibt es unter folgender Adresse: 


http://Is12-www.cs.tu-dortmund.de/-marwedel/es-book/ 


Diese Seite beinhaltet Verweise auf Foliensätze, Simulationswerkzeuge, Feh- 
lerkorrekturen, Vorlesungsvideos und weiteres zugehöriges Material. Videos sind 
direkt verfügbar von 


https://www.youtube.com/user/cyphysystems 


Leser und Leserinnen, die Fehler entdecken oder Vorschläge zur Verbesserung 
des Buchs machen möchten, wenden sich bitte per E-Mail an: 


peter.marwedel@tu-dortmund.de 


Aufgrund der Verfügbarkeit dieses Buches und der Videos ist es zu empfehlen, 
Lehre nach dem flipped classroom-Konzept [376] zu erproben. Bei diesem Konzept 
werden die Funktionen von Stoffvorstellungen in der Hochschule und Vertiefungs- 
phasen zu Hause weitgehend vertauscht: Ein erstes Kennenlernen des Stoffes findet 
anhand der Videos oder des Buches zu Hause statt, ein Vertiefen erfolgt in Grup- 
penarbeit während der Anwesenheit in der Hochschule. Auf diese Weise werden 
die Fähigkeiten zur Problemlösung, zum Teamwork und die sozialen Kompeten- 
zen gestärkt. Auch wird die Verfügbarkeit des Internets genutzt, um Lehrmethoden 
für eingeschriebene Studierende zu verbessern. In Pandemiephasen, wie der von 
COVID-19, ist es vorteilhaft, dass Anwesenheitsphasen an der Hochschule auf das 
notwendige Minimum beschränkt werden können. Vom flipped-classroom-Konzept 
zu unterscheiden sind Massive Open Online Courses (MOOCs), die v.a. entfernt le- 
bende Studierende ansprechen sollen. Zu lösende Aufgaben können entweder diesem 
Buch oder anderen Büchern (wie z.B. [593, 81, 174]) entnommen werden. 

Beim flipped classroom-Konzept können Laborphasen vollständig genutzt wer- 
den, um praktische Erfahrungen mit CPS zu bekommen. Zu diesem Zweck sollte 
ein Kurs, der dieses Buch benutzt, um ein spannendes Labor ergänzt werden, in dem 
beispielsweise kleine Roboter (wie Lego Mindstorms"“) oder Mikrocontroller (wie 
Raspberry Pi, Arduino oder Odroid) benutzt werden. Für die handelsüblichen Mi- 
krocontroller steht meist auch Lehrmaterial zur Verfügung. Eine andere Möglichkeit 
besteht in der Nutzung von Werkzeugen zur Simulation von endlichen Automaten. 
Empfohlen wird eine Ergänzung um eine Lehrveranstaltung zur Datenanalyse bzw. 
zum Maschinellen Lernen [205, 188, 559, 453]. 


Voraussetzungen 


Das Buch setzt ein grundlegendes Verständnis verschiedener Bereiche voraus: 
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e Programmierung von Rechnern (mit Grundlagen des Software Engineerings) 
einschließlich erster Erfahrungen mit der Programmierung von Mikrocontrollern, 

e Algorithmen (Graphenalgorithmen und Optimierungsalgorithmen wie Branch- 
and-Bound) einschließlich des Konzeptes der NP-Vollständigkeit, 

e Rechnerorganisation, z.B. auf der Ebene des einführenden Buchs von J.L. Hen- 
nessy und D.A. Patterson [213] einschließlich endlicher Automaten, 

e Grundlagen von Betriebssystemen (BS), 

e Rechnernetz-Grundlagen (wichtig für das Internet der Dinge), 

e grundlegende mathematische Konzepte (z.B. Tupel, Integrale, lineare Algebra), 

e elektrotechnische (ET) Grundlagen sowie Digitalschaltungen wie Gatter und Re- 
gister. 


Diese Voraussetzungen lassen sich in verschiedene Kurse einteilen, wie in Abb. 
1.7 dargestellt. Fehlende Grundkenntnisse im Bereich elektrischer Netzwerke, von 
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Abb. 1.7 Positionierung der einzelnen Themen dieses Buches 


Operationsverstärkern, von Speicherverwaltung und von Ganzzahliger Linearer Pro- 
grammierung können durch Lesen der Anhänge dieses Buches teilweise ausgeglichen 
werden. Kenntnisse in Statistik und Fourier-Reihen sind nützlich. 


Empfohlene zusätzliche Lehrveranstaltungen 


Das Buch sollte durch aufbauende Kurse ergänzt werden, die speziellere Kenntnisse 
in einigen der folgenden Gebiete vermitteln (siehe die untere Zeile von Abb. 1.7)®: 


e Regelungstechnik, 
e Digitale Signalverarbeitung, 
e Bilderkennung, 


8 Die Aufteilung in grundlegende und weiterführende Lehrveranstaltungen kann sich dabei zwi- 
schen einzelnen Universitäten unterscheiden. 
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e Echtzeitsysteme, Echtzeitbetriebssysteme und Scheduling, 

e Robotik, 

e Anwendungsgebiete wie Telekommunikation, Kraftfahrzeuge, medizinische Ge- 
rate und Gebäudeautomatisierung, 

¢ Middleware, 

e Spezifikationssprachen und -modelle für eingebettete Systeme, 

e Sensoren und Aktuatoren, 

e Verlässlichkeit von Rechnersystemen, 

e energiesparende Entwurfstechniken, 

e physikalische Aspekte von CPS, 

e rechnergestiitzte Entwurfswerkzeuge fiir anwendungsspezifische Hardware, 

e formale Verifikation von Hardwaresystemen, 

« Test von Hardware- und Softwaresystemen, 

° Leistungsbewertung von Rechensystemen, 

e ubiquitous computing, 

e Kommunikationstechniken für das Internet der Dinge (IoT), 

e gesellschaftliche Bedeutung und Wirkung eingebetteter, cyber-physikalischer und 
IoT-Systeme sowie 

e rechtliche Aspekte derselben Systeme. 


1.6 Entwurfsflüsse 


Der Entwurf der betrachteten Systeme stellt eine recht komplexe Aufgabe dar, die in 
eine Reihe von Unteraufgaben aufgeteilt werden muss. Diese Unteraufgaben müssen 
nacheinander und einige müssen mehrfach ausgeführt werden. 

Der Entwurfsinformationsfluss beginnt mit Ideen im Kopf von Personen. Die- 
se Ideen sollten bereits Wissen über den Anwendungsbereich beinhalten. Die Ideen 
müssen in einer Entwurfsspezifikation festgehalten werden. Zudem sind üblicherwei- 
se Hardware- und Systemsoftwarekomponenten vorhanden, diese sollten möglichst 
wiederverwendet werden (siehe Abb. 1.8). Bei diesem Diagramm (wie auch in weite- 
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Abb. 1.8 Vereinfachter Entwurfsfluss 
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ren ähnlichen Diagrammen in diesem Buch) verwenden wir Rechtecke mit abgerun- 
deten Ecken zur Darstellung gespeicherter Informationen und herkömmliche 
Rechtecke für Transformationen von Informationen. Insbesondere kann die Spei- 
cherung zentral in einer Entwurfsdatenbank erfolgen. Diese Datenbank ermöglicht 
es, einen Überblick über die Entwurfsmodelle zu behalten. Normalerweise sollten 
die Entwurfsdaten einer Versionsverwaltung unterliegen, die z.B. mittels der Werk- 
zeuge CVS [87], SVN [108] oder git (siehe https://www.git-scm.com) verfügbar ist. 
Eine gute Entwurfsdatenbank sollte auch eine Schnittstelle zur Entwurfsverwaltung 
besitzen, die es erlaubt, einen Überblick über die Anwendbarkeit von Entwurfs- 
werkzeugen und -folgen zu erhalten. Diese Schnittstelle kann als graphische Be- 
nutzerschnittstelle (engl. Graphical User Interface (GUI) realisiert werden, um die 
Benutzung zu vereinfachen. Die Entwurfsdatenbank und die Benutzerschnittstelle 
können zu einer integrierten Entwicklungsumgebung (engl. Integrated Develop- 
ment Environment (IDE)) zusammengefasst werden, die auch design framework 
genannt wird (siehe z.B. [346]). Eine integrierte Entwicklungsumgebung verwaltet 
die Abhängigkeiten zwischen den Werkzeugen und der Entwurfsinformation. 

Die Verwendung der Datenbank ermöglicht es, Entwurfsentscheidungen in ei- 
nem iterativen Ablauf zu treffen. Für jeden Schritt muss die Information über das 
Entwurfsmodell abgerufen und anschließend bewertet werden. 

In den einzelnen Entwurfsdurchläufen werden Anwendungen auf Ausführungs- 
plattformen abgebildet, zudem werden neue (partielle) Entwurfsinformationen er- 
zeugt. Dies beinhaltet die Abbildung von Operationen auf nebenläufige Tasks, 
die Abbildung von Operationen auf Hardware oder Software (Hardware/Software- 
Partitionierung genannt), die Übersetzung und das Scheduling. 

Entwürfe sollten in Hinblick auf verschiedene Ziele wie Rechenleistung (Per- 
formanz), Verlässlichkeit, Energieverbrauch, thermisches Verhalten usw. bewertet 
(evaluiert) werden. Der aktuelle Stand der Technik garantiert nicht, dass irgendeiner 
dieser Entwurfsschritte korrekt ist. Daher ist es auch erforderlich, einen Entwurf 
zu validieren. Die Validierung umfasst den Abgleich von Zwischenversionen und 
der endgültigen Version von Entwurfsbeschreibungen mit anderen Beschreibungen. 
Jeder neue Entwurf sollte bewertet und validiert werden. 

Da die Effizienz eingebetteter Systeme besonders wichtig ist, sind Optimierun- 
gen erforderlich. Dabei ist eine Vielzahl von Optimierungen verfügbar, beispiels- 
weise High-Level-Transformationen (wie z.B. erweiterte Schleifentransformationen) 
und Energieoptimierungen. 

Wenn Überlegungen zur Testbarkeit schon in frühen Entwurfsphasen berücksich- 
tigt werden sollen, müssen Tests in die dargestellten Entwurfsiterationen integriert 
werden. In Abb. 1.8 wurde die Testerzeugung als optionaler Schritt während der 
Entwurfsiterationen hinzugefügt (dargestellt durch das gestrichelte Rechteck). Wenn 
die Testerzeugung nicht Bestandteil der einzelnen Entwurfsiterationen ist, dann muss 
sie nach Fertigstellung des Entwurfs durchgeführt werden. Am Ende jedes einzelnen 
Schrittes sollte die Datenbank aktualisiert werden. 

Die Details des Informationsflusses zwischen Datenbank, Anwendungsabbildung, 
Bewertung, Validierung, Optimierung, Testbarkeitsüberlegungen und der Speiche- 
rung von Entwurfsinformationen können durchaus abweichen. Abhängig von der 
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konkret verwendeten Entwurfsmethode können diese Aktionen auf vielfältige Wei- 
se miteinander verknüpft sein. Dieses Buch gibt einen breiten Überblick über den 
Entwurf eingebetteter Systeme und ist nicht auf bestimmte Entwurfsflüsse und Werk- 
zeuge festgelegt. Daher haben wir keine feste Liste von Entwurfsschritten vorgege- 
ben. Wir können die in Abb. 1.8 enthaltenen Schleifen für jede Entwurfsumgebung 
„abrollen” und einzelnen Entwurfsschritten Namen zuordnen. 

Dies führt bei Einsatz von SpecC [173] zu dem in Abb. 1.9 dargestellten Entwurfs- 
fluss. Der gezeigte Fall beinhaltet eine bestimmte Menge an Entwurfsschritten, wie 
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Abb. 1.9 Entwurfsfluss fiir die SpecC-Werkzeuge (vereinfacht) 


Architekturerkundung, Kommunikationssynthese und Software- wie Hardwareüber- 
setzung. Die genaue Bedeutung dieser Begriffe ist fiir dieses Buch nicht relevant. In 
Abb. 1.9 sind Validierung und Bewertung fiir jeden der Schritte explizit als Bestand- 
teil eines größeren Schrittes dargestellt. 

Eine weitere Instanz von Abb. 1.8 ist in Abb. 1.10 dargestellt. Dies ist der Ent- 
wurfsfluss des V-Modells [550], der für viele deutsche IT-Projekte, speziell im 
öffentlichen Sektor und darüber hinaus, verbindlich ist. Abb. 1.10 zeigt die durch- 
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Abb. 1.10 Entwurfsfluss für das V-Modell 


zuführenden Schritte im Einzelnen. Diese Schritte entsprechen bestimmten Phasen 
des Software-Entwicklungsprozesses (auch hier ist die genaue Bedeutung im Rah- 
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men dieses Buches nicht relevant). Dieses Diagramm fasst Entwurfsentscheidungen, 
Bewertung und Validierung in einem einzelnen Schritt zusammen. Anwendungs- 
wissen, Systemsoftware und Systemhardware werden nicht explizit dargestellt. Das 
V-Modell beinhaltet auch ein Modell der Integrations- und Testphase (rechter Zweig 
des Diagramms). Damit wird das Testen mit in die Integrationsphase einbezogen. 
Das dargestellte Modell entspricht dem V-Modell Version „97”. Das aktuellere V- 
Modell XT ermöglicht eine verallgemeinerte Menge an Entwurfsschritten. Diese 
Erweiterung passt sehr gut zu unserer Interpretation von Entwurfsfliissen in Abb. 
1.8. Andere iterative Ansätze sind das Wasserfallmodell und das Spiralmodell. 
Weitere Informationen zum Software-Engineering fiir eingebettete Systeme finden 
sich in dem Buch von J. Cooling [109]. 

Unser allgemeiner Entwurfsfluss passt auch zu Flussmodellen, die im Hardwa- 
reentwurf zum Einsatz kommen. Ein weit verbreitetes Modell ist das Y-Diagramm 
(engl. Y-chart) von Gajski und Kuhn [171] (siehe Abb. 1.11). Die Autoren un- 
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Abb. 1.11 Gajskis Y-Diagramm und Entwurfspfad (rot, fett) 


terscheiden drei Dimensionen von Entwurfsinformationen: Verhalten, Struktur und 
Layout. Die erste Dimension stellt ausschließlich das Verhalten dar. Ein Modell auf 
hoher Abstraktionsebene würde lediglich das Gesamtverhalten beschreiben, woge- 
gen detailliertere Modelle das Verhalten einzelner Komponenten beschreiben wür- 
den. Modelle der zweiten Dimension beinhalten Strukturinformationen wie z.B. 
Informationen über Hardwarekomponenten. In dieser Dimension könnten Beschrei- 
bungen auf hoher Abstraktionsebene Prozessoren entsprechen, Beschreibungen auf 
unterster Ebene entsprächen Transistoren. Die dritte Dimension stellt die geometri- 
sche Layout-Information eines Chips dar. Entwurfspfade beginnen meist mit einer 
grobgranularen Verhaltensbeschreibung und enden mit einer feingranularen geome- 
trischen Beschreibung. Entlang dieses Pfades entspricht jeder Schritt einer Iteration 
unseres generischen Entwurfsflussmodells. Im Beispiel von Abb. 1.11 erfolgt zu 
Beginn eine Verfeinerung im Verhaltensbereich. Der zweite Entwurfsschritt bildet 
das Verhalten auf Strukturelemente ab usw. Schließlich entsteht eine detaillierte 
geometrische Beschreibung des Chip-Layouts. 

Diese drei Beispiele zeigen, dass der iterative Fluss von Abb. 1.8 in einer Reihe von 
Entwurfsflüssen verwendet wird. Die Beschaffenheit der einzelnen Iterationen aus 
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Abb. 1.8 wird dabei oft unterschiedlich betrachtet. Idealerweise würden wir zunächst 
die Eigenschaften unseres Systems beschreiben wollen und dann den Rest von einem 
geeigneten leistungsfähigen Werkzeug erledigen lassen. Eine solche automatische 
Erzeugung von Entwurfsdetails wird Synthese genannt. 


Definition 1.12 (Marwedel [371]): „Synthese ist der Vorgang, die Beschreibung 
eines Systems in Form von Komponenten auf einer niederen Abstraktionsebene aus 
einer Beschreibung des erwarteten Verhaltens auf einer höheren Ebene erzeugen zu 
lassen.” 


Bei einer automatischen Synthese soll dieser Vorgang automatisch ablaufen. Ma- 
nuelle Entwurfsschritte können vermieden werden, wenn automatische Synthese 
erfolgreich ist. Das Ziel der automatischen Synthese wurde von Gajski [172] im 
„describe-and-synthesize”-Paradigma verfolgt. Dieses Paradigma steht im Gegen- 
satz zu dem weiter verbreiteten „specify-explore-refine”-Paradigma, auch bekannt 
als „entwerfe und simuliere”. Der zweite Begriff betont, dass der manuelle Entwurf 
meist mit Simulation kombiniert werden muss, um beispielsweise Entwurfsfehler zu 
finden. Simulation ist hier wichtiger als bei der automatischen Synthese. 


1.7 Struktur dieses Buches 


Die Struktur dieses Buches folgt dem oben gezeigten Entwurfsfluss. Kapitel 2 gibt 
einen Überblick über Spezifikationstechniken, -sprachen und -modelle. Wichtige 
Hardwarekomponenten eingebetteter Systeme und die Schnittstelle zwischen der 
physischen Umgebung und der Informationsverarbeitung werden im Kapitel 3 vorge- 
stellt. Kapitel 4 behandelt Systemsoftwarekomponenten, insbesondere eingebettete 
Betriebssysteme. Kapitel 5 beschreibt die Grundzüge der Bewertung und Validierung 
eingebetteter Systeme. Die Abbildung von Anwendungen auf Ausführungsplattfor- 
men ist einer der wichtigsten Schritte im Entwurfsprozess eingebetteter Systeme. Da- 
bei ist das Scheduling ein wesentlicher Teil einer solchen Abbildung. Dafür werden 
Standard-Techniken im Kapitel 6 beschrieben. Um effiziente Entwürfe zu erzeugen, 
werden viele Optimierungstechniken benötigt. Eine Auswahl von Techniken aus der 
großen Menge verfügbarer Optimierungen wird im Kapitel 7 vorgestellt. Kapitel 8 
enthält eine kurze Einführung in den Test kombinierter Hardware/Software-Systeme. 
Der Anhang beinhaltet eine Beschreibung einer Standard-Optimierungstechnik, ei- 
nige Grundlagen zum Verständnis einer der Schaltungen aus Kapitel 3 und Grund- 
wissen zur Speicherorganisation. 

In einigen Fällen kann es erforderlich sein, spezielle Hardware für eine bestimm- 
te Anwendung zu entwerfen oder eine Prozessorarchitektur entsprechend zu opti- 
mieren. Dieses Buch befasst sich jedoch nicht mit dem Hardwareentwurf. Coussy 
and Morawiec [113] geben einen Überblick über High-Level-Hardwaresynthese- 
Techniken. 

Der Inhalt dieses Buchs unterscheidet sich vom Inhalt der meisten anderen Bü- 
cher zum Entwurf eingebetteter oder cyber-physikalischer Systeme. Der Schwer- 


28 1 Einleitung 


punkt vieler solcher Bücher lag früher auf der Verwendung von Mikrocontrollern, 
deren Speicher, Ein/Ausgabegeräten und der /nterrupt-Struktur. Es gibt viele derar- 
tige Bücher [176, 37, 175, 177, 280, 318, 426]. Wir sind der Auffassung, dass es die 
steigende Komplexität eingebetteter Systeme erfordert, diesen Schwerpunkt so zu 
erweitern, dass zumindest unterschiedliche Spezifikationsansätze, Grundlagen von 
Hardwarekomponenten, die Abbildung von Anwendungen auf Ausführungsplatt- 
formen sowie die Bewertung, Validierung und Optimierungstechniken vorgestellt 
werden. Im vorliegenden Buch betrachten wir alle diese Bereiche. Das Ziel ist es, 
Studierenden eine Einführung zu eingebetteten und cyber-physikalischen Systemen 
zu geben, die sie in die Lage versetzt, die verschiedenen Themenbereiche einschätzen 
zu können. 

Für weiterführende Informationen möchten wir auf eine Reihe von Quellen ver- 
weisen, von denen einige auch bei der Vorbereitung dieses Buches zum Einsatz 
kamen: 


e Symposien mit Schwerpunkt eingebettete/cyber-physikalische Systeme sind die 
Embedded Systems Week (siehe http://www.esweek.org) und die Cyber-Physical 
Systems Week (siehe http://www.cpsweek.org). 

e Die Webseite der amerikanischen virtuellen CPS-Organisation liefert zahlreiche 
Hinweise auf laufende Arbeiten und deren Ergebnisse [115]. 

e Die Webseiten einer Interessengruppe der ACM [9] befassen sich mit eingebet- 
teten Systemen. 

e Die Webseiten des europäischen Exzellenznetzwerks für eingebettete Systeme 
und Echtzeitsysteme [24] beinhalten viele Links zum Thema. 

e Ein Buch von Edward Lee et al. befasst sich auch mit physikalischen Aspekten 
von cyber-physikalischen Systemen [335]. 

e Die Workshopreihe Workshop on Embedded and Cyber-Physical Systems Educa- 
tion (WESE) behandelt aktuelle Ansätze für die Lehre zu eingebetteten Systemen; 
Ergebnisse des Workshops im Jahr 2018 sind in [89] zu finden. Die Lehre ist auch 
Gegenstand des ersten und einzigen Workshops über Lehre im Bereich CPS [425]. 

e Andere Informationsquellen zu eingebetteten Systemen sind Bücher von Laplante 
[323], Vahid [552], die ARTIST Roadmap [63], das „Embedded Systems Hand- 
book” [614] sowie Bücher von Gajski et al. [174] und Popovici et al. [457]. 

e Eine große Anzahl von Quellen befasst sich mit Spezifikationssprachen. Zu diesen 
zählen ältere Bücher von Young [609], Burns and Wellings [79], Berge [566] und 
de Micheli [124]. Weiterhin ist eine große Menge an Informationen über neue 
Sprachen wie SystemC [408], SpecC [173] und Java [573, 131, 71] verfügbar. 

e Echtzeit-Scheduling wird umfassend in den Büchern von Buttazzo [81], von 
Krishna und Shin [311] sowie von Baruah et al. [38] behandelt. 

e Ansätze für den Entwurf und die Verwendung von Echtzeit-Betriebssystemen 
(RTOS) werden in einem Buch von Kopetz vorgestellt [304]. 

e Robotik ist ein eng mit eingebetteten und cyber-physikalischen Systemen verbun- 
denes Gebiet. Wir empfehlen das Buch von Siciliano et al. [487]. 

¢ Es gibt Bücher und Artikel, die auf das Internet der Dinge fokussiert sind [185, 
193, 192]. 
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e Sprachen und Verifikation sind der Schwerpunkt eines Buches von Haubelt und 
Teich [207]. 


1.8 Aufgaben 


Die folgenden Aufgaben sollten entweder zu Hause oder während einer Anwesen- 
heitsphase nach dem flipped classroom-Konzept [376] bearbeitet werden: 


1.1: Nennen Sie einige der Definitionen des Begriffs „eingebettetes System”! 


1.2: Definieren Sie den Begriff „cyber-physikalisches System”! Sehen Sie einen Un- 
terschied zwischen den Begriffen „eingebettetes System” und „cyber-physikalisches 
System”? 


1.3: Was ist das Internet der Dinge (IoT)? 
1.4: Was ist das Ziel der Initiative „Industrie 4.0”? 


1.5: Auf welche Weise deckt dieses Buch den Entwurf von CPS- und IoT-Systemen 
ab? 


1.6: In welchen Anwendungsbereichen sehen Sie Potential für den Einsatz von CPS- 
und IoT-Systemen? Wo erwarten Sie große Veränderungen durch die IT? 


1.7: Warum sind eingebettete Systeme und cyber-physikalische Systeme wichtig? 


1.8: Welche Herausforderungen müssen wir bewältigen, wenn wir das Potential von 
eingebetteten und cyber-physikalischen Systemen ausnutzen wollen? 


1.9: Was ist eine harte Zeitschranke? Was ist eine weiche Zeitschranke? 
1.10: Was ist der Zeno-Effekt? 

1.11: Was ist adaptives Abtasten? 

1.12: Nach welchen Kriterien können wir eingebettete Systeme bewerten? 


1.13: Aus welchen Gründen und für welche Systeme betrachten wir die Energieef- 
fizienz? 


1.14: Was sind die Hauptunterschiede zwischen Anwendungen auf PCs und Anwen- 
dungen in eingebetteten Systemen? 


1.15: Was ist ein reaktives System? 


1.16: Auf welcher Webseite gibt es ergänzendes Material zu diesem Buch? 
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1.17: Vergleichen Sie das Curriculum an Ihrer Hochschule mit dem Programm, 
das hier in der Einleitung angegeben ist! Welche Voraussetzungen fehlen an Ihrer 
Hochschule? Welche fortgeschrittenen Kurse sind verfiigbar? 


1.18: Was ist das flipped classroom-Konzept? 
1.19: Wie modellieren wir Entwurfsfliisse? 
1.20: Was ist das V-Modell? 


1.21: Wie definieren Sie ,,Synthese”? 


Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 Internatio- 
nal Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nut- 
zung, Vervielfaltigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und For- 
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einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenom- 
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Kapitel 2 mM 
Spezifikation und Modellierung “pate 


Wie können wir das System, welches wir entwerfen wollen, beschreiben und wie 
können wir partielle Entwürfe darstellen? Eine Antwort auf diese Fragen gibt die- 
ses Kapitel, in dem wir Modelle und Beschreibungstechniken vorstellen, mit denen 
sowohl die Spezifikation wie auch Zwischenschritte dargestellt werden können. Als 
erstes werden wir Anforderungen an Modellierungstechniken erfassen. Danach wer- 
den wir beliebte Berechungsmodelle zusammen mit zugehörigen Sprachen vorstel- 
len. Dazu gehören Modelle für frühe Entwurfsphasen, Automaten-basierte Modelle, 
Datenfluss, Petrinetze, diskrete Ereignismodelle, von-Neumann-Sprachen und Ab- 
straktionsebenen für die Hardware-Modellierung. Schließlich werden wir verschie- 
dene Berechnungsmodelle vergleichen und Übungsaufgaben vorstellen. 


2.1 Anforderungen 


In Übereinstimmung mit dem vereinfachten Entwurfsfluss aus Abb. 1.8 werden 
wir zunächst Anforderungen und Ansätze für die Spezifikation eingebetteter und 
cyber-physikalischer Systeme präsentieren. Spezifikationen solcher Systeme stel- 
len Modelle des zu entwerfenden Systems bereit. Das führt zu der Frage, was ist 
eigentlich ein Modell? Eine mögliche Definition stammt von Jantsch. 


Definition 2.1 (Jantsch [269]): „Ein Modell ist die Vereinfachung einer anderen 
Einheit, die ein physischer Gegenstand oder ein anderes Modell sein kann. Das 
Modell enthält genau diejenigen Merkmale und Eigenschaften der modellierten 
Einheit, die für die gegebene Aufgabe relevant sind. Ein Modell ist minimal im 
Hinblick auf eine Aufgabe, wenn es keine anderen Eigenschaften enthält als jene, 
die für die Aufgabe relevant sind”. 


Modelle werden in Sprachen beschrieben. Dabei sollten Sprachen die folgenden 
Eigenschaften darstellen können!: 


! Diese Liste verwendet Informationen aus den Büchern von Burns et al. [79], Bergé et al. [566] 
und Gajski et al. [172] 
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Hierarchie: Menschen sind im Allgemeinen nicht dazu in der Lage, Systeme mit 
vielen Objekten (wie z.B. Zustände oder Komponenten) zu verstehen, in denen 
die Objekte in komplexen Zusammenhängen miteinander stehen. Um ein reales 
System zu beschreiben, benötigt man mehr Objekte als ein Mensch erfassen 
kann. Die Einführung von Hierarchieebenen (in Verbindung mit Abstraktion) 
ist einer der besten Wege, dieses Problem zu lösen. Hierarchie kann so eingesetzt 
werden, dass ein Mensch immer nur eine kleine Anzahl von Objekten auf einmal 
überschauen muss. 

Es gibt zwei Arten von Hierarchien: 


— Verhaltenshierarchien: Verhaltenshierarchien enthalten Objekte, die notwen- 
dig sind, um das Verhalten des Gesamtsystems zu beschreiben. Beispiele hier- 
für sind Zustände, Ereignisse und Ausgabesignale. 

— Strukturelle Hierarchien: Strukturelle Hierarchien beschreiben, wie das Ge- 
samtsystem aus einzelnen physischen Komponenten zusammengesetzt ist. 
Eingebettete Systeme können z.B. aus Prozessoren, Speichern, Aktuatoren und 
Sensoren bestehen. Prozessoren wiederum enthalten Register, Multiplexer und 
Addierer. Multiplexer bestehen aus Gattern. 


Komponentenbasierter Entwurf [489]: Es muss „einfach” sein, das Verhal- 
ten eines Systems vom Verhalten seiner Komponenten abzuleiten. Wenn zwei 
Komponenten miteinander verbunden werden, sollte das sich ergebende neue 
Verhalten vorhersagbar sein. Wenn wir beispielsweise eine zusätzliche Kom- 
ponente wie ein Navigationssystem in ein Auto integrieren möchten, sollte der 
Einfluss dieser zusätzlichen Komponente auf das Verhalten des Gesamtsystems 
(unter Berücksichtigung von Bussen usw.) vorhersagbar bleiben. 
Nebenläufigkeit: Viele praxisrelevante Systeme sind verteilte, nebenläufige Sys- 
teme, die aus mehreren Komponenten bestehen. Daher muss Nebenläufigkeit oder 
Parallelität einfach zu spezifizieren sein. Leider kann der Mensch nebenläufige 
Vorgänge nur schwer verstehen. Daher sind viele der Probleme, die bei realen 
Systemen auftreten, eine Folge von mangelndem Verständnis möglicher Abläufe 
in parallelen Systemen. 

Synchronisation und Kommunikation: Komponenten eines Systems müssen 
miteinander kommunizieren und die Verwendung von Ressourcen synchronisie- 
ren können. Ohne Kommunikation wäre eine Kooperation zwischen Komponen- 
ten nicht realisierbar und jede Komponente müsste für sich alleine verwendet 
werden. Weiterhin muss es eine Möglichkeit geben, die Benutzung von Res- 
sourcen auszuhandeln. So ist es zum Beispiel häufig notwendig, gegenseitigen 
Ausschluss zu realisieren. 

Zeitverhalten: Viele eingebettete Systeme müssen Echtzeitanforderungen erfül- 
len. Explizite Zeitbedingungen sind daher eine der wichtigsten Eigenschaften 
eingebetteter Systeme, was durch den Begriff „cyber-physikalische Systeme” 
noch besser zum Ausdruck kommt. Zeit ist eine der wichtigsten Dimensionen 
der Physik. Daher müssen Zeitbedingungen in der Spezifikation eingebetteter 
und cyber-physikalischer Systeme erfasst werden. 
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Die Standardtheorien der Informatik modellieren Zeit allerdings nur auf eine sehr 
abstrakte Art. Die O-Notation? ist ein Beispiel dafür. Sie gibt nur Wachstums- 
raten von Funktionen wieder und wird haufig genutzt, um die Laufzeiten von 
Algorithmen zu modellieren. Dabei ist sie aber nicht dazu in der Lage, echte 
Ausführungszeiten zu ermitteln. Physikalische Größen besitzen Einheiten, die 
O-Notation jedoch nicht. Damit kann sie nicht zwischen Femtosekunden und 
Jahrhunderten unterscheiden. Ähnlich verhält es sich mit Eigenschaften der Ter- 
minierung von Prozessen. Es gibt Beweise, die zeigen, dass ein bestimmter Al- 
gorithmus irgendwann einmal terminiert. Bei Echtzeitsystemen hingegen müssen 
wir nachweisen, dass ein Algorithmus innerhalb einer vorgegebenen Zeitspanne 
terminiert, aber der Algorithmus als Ganzes muss evtl. ausgeführt werden, bis 
die Spannungsversorgung ausgeschaltet wird. 

Burns und Wellings [79] definieren die folgenden vier Kontexte für die Angabe 
von Zeiten in Spezifikationssprachen: 


— Methoden zur Messung der vergangenen Zeit: 

Viele Anwendungen müssen überprüfen, wie viel Zeit seit dem Ende einer 
bestimmten Berechnung vergangen ist. Dies ließe sich durch einen Zeitgeber 
(engl. fimer) realisieren. 

— Eine Möglichkeit, Prozesse? um eine bestimmte Zeit zu verzögern: 
Echtzeitsprachen stellen üblicherweise Möglichkeiten zur Verfügung, die Aus- 
führung hinauszuzögern. Leider garantieren die verbreiteten Softwareimple- 
mentierungen eingebetteter Systeme keine präzisen Verzögerungen. Wir neh- 
men an, dass ein Prozess T um eine Zeit A verzögert werden soll. Meist wird 
dies implementiert, indem der Zustand von Prozess t im Betriebssystem von 
„laufend” oder „bereit” auf „blockiert gesetzt wird. Am Ende des Zeitinter- 
valls wird der Zustand von r dann von „blockiert” auf „bereit” gesetzt. Dies hat 
aber nicht zur Folge, dass der Prozess sofort danach ausgeführt wird. Wenn 
gleichzeitig ein Prozess mit höherer Priorität läuft oder keine Verdrängung 
(kein Anhalten eines laufenden Prozesses, engl. preemption) verwendet wird, 
ist die wirkliche Verzögerung des Prozesses größer als A. 

— Eine Möglichkeit, Timeouts anzugeben: 

In vielen Situationen muss auf das Eintreten eines bestimmten Ereignisses 
gewartet werden. Wenn dieses Ereignis nicht innerhalb einer bestimmten 
Zeitspanne auftritt, möchten wir darüber informiert werden. So könnten wir 
beispielsweise auf eine Antwort von einer Netzwerkverbindung warten. Wir 
würden gerne informiert werden, wenn diese Antwort nicht innerhalb einer 
bestimmten Zeit A angekommen ist. Dies ist der Zweck von Timeouts. Die 
meisten Echtzeitsprachen besitzen auch ein Timeout-Sprachelement. Die Im- 
plementierung von Timeouts bringt dieselben Probleme mit sich, wie sie bereits 
für Verzögerungen beschrieben wurden. 

— Methoden, um Zeitschranken und Abläufe (Schedules) anzugeben: 


? Gemäß Seite 22 hier als bekannt vorausgesetzt. 
3 Prozesse sind in Ausführung befindliche Programme, siehe Definition 2.3. 
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Viele Anwendungen miissen bestimmte Berechnungen in begrenzter Zeit aus- 
führen. So müssen beispielsweise die Airbags eines Autos innerhalb von rund 
zehn Millisekunden zünden, nachdem ein Sensor einen Unfall angezeigt hat. 
Hier müssen wir garantieren, dass die Software in der vorgegebenen Zeit ent- 
scheidet, ob die Airbags gezündet werden sollen oder nicht. Wenn die Airbags 
zu spät zünden, könnten Insassen verletzt werden. Leider erlauben es die meis- 
ten Sprachen nicht, Zeitschranken anzugeben. Wenn sie angegeben werden 
können, dann zumeist in separaten Steuerungsdateien oder in Dialogfenstern. 
Die Situation wäre aber immer noch schwierig zu beherrschen, wenn sich 
Zeitschranken angeben ließen. Der Grund hierfür ist, dass moderne Hardware 
kein gut vorhersagbares Zeitverhalten besitzt. Caches, blockierte Pipelines, 
spekulative Ausführung, Verdrängung von Prozessen, Unterbrechungen (engl. 
interrupts) usw. haben alle einen nur schwer vorhersagbaren Einfluss auf die 
Ausführungszeit. Entsprechend ist die Zeitanalyse eine sehr schwierige Ent- 
wurfsaufgabe. 


e Zustandsorientiertes Verhalten: In Kapitel 1 wurde schon erwähnt, dass Auto- 
maten eine gute Darstellungsmöglichkeit für reaktive Systeme sind. Aus diesem 
Grund sollte es einfach sein, zustandsorientiertes Verhalten, wie es endliche Au- 
tomaten zeigen, zu beschreiben. Klassische Automatenmodelle sind allerdings 
nicht ausreichend, da sie weder Zeitbedingungen noch Hierarchie unterstützen. 

« Ereignisbehandlung: Da eingebettete Systeme oft reaktive Systeme sind, müssen 
Mechanismen zur Beschreibung von Ereignissen existieren. Solche Ereignisse 
können externe (von der Umwelt erzeugte) oder interne (von Komponenten des 
Systems erzeugte) Ereignisse sein. 

e Ausnahmeorientiertes Verhalten: In vielen realen Systemen treten Ausnahmen 
auf. Um verlässliche Systeme entwerfen zu können, muss die Behandlung solcher 
Ausnahmesituationen einfach zu beschreiben sein. Es ist nicht ausreichend, wenn 
man die Ausnahmebehandlung z.B. für jeden einzelnen Zustand angeben muss, 
wie das etwa bei klassischen Automatenmodellen der Fall ist. 


Beispiel 2.1: In Abb. 2.1 soll die Eingabe k das Auftreten einer Ausnahme darstel- 
len. Die Angabe einer solchen Ausnahme für jeden Zustand lässt das Diagramm 


Abb. 2.1 Zustandsdiagramm 
mit Ausnahme k 


komplex werden. Für größere Diagramme mit vielen Übergängen würde die Si- 
tuation noch unübersichtlicher werden. Auf Seite 56 werden wir zeigen, wie man 
alle diese Transitionen durch eine einzige ersetzen kann (siehe Abb. 2.12). V 
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Programmiersprachenelemente: Programmiersprachen sind eine weit verbrei- 
tete Methode zur Beschreibung von Berechnungsvorschriften. Daher sollten Ele- 
mente von Programmiersprachen in der Spezifikation verwendet werden können. 
Die bekannten Zustandsdiagramme erfüllen diese Anforderung nicht. 
Ausführbarkeit: Eine Spezifikation stimmt nicht automatisch mit der ursprüng- 
lichen Idee des Entwicklers überein. Das Ausführen der Spezifikation stellt eine 
Möglichkeit der Plausibilitätsprüfung für den Entwurf dar. Spezifikationen, die 
Programmiersprachenelemente verwenden, sind in diesem Zusammenhang von 
Vorteil. 

Unterstützung für den Entwurf großer Systeme: Eingebettete Systeme ver- 
wenden immer größere und komplexere Programme. Die Softwaretechnologie 
verfügt über Mechanismen wie z.B. Objektorientierung, um solche großen Sys- 
teme handhabbar zu machen. Solche Mechanismen sollten auch in der Spezifika- 
tionsmethodik zum Einsatz kommen. 

Unterstützung von spezifischen Anwendungsgebieten: Es wäre wünschens- 
wert, wenn ein und dieselbe Spezifikationstechnik für alle möglichen eingebet- 
teten Systeme verwendet werden könnte, da dies den Aufwand für die Entwick- 
lung der Techniken minimieren würde. Allerdings ist die mögliche Bandbreite 
von Anwendungsgebieten sehr groß (siehe Abschnitt 1.2). Es ist daher kaum zu 
erwarten, dass eine einzige Sprache die Belange aller Anwendungsbereiche glei- 
chermaßen gut abdecken kann. Beispielsweise können kontrollflussdominierte, 
datenflussdominierte, zentralisierte oder verteilte Anwendungsgebiete von spezi- 
fischer Werkzeugunterstützung für den jeweiligen Bereich profitieren. 
Lesbarkeit: Selbstverständlich muss eine Spezifikation von Menschen gelesen 
werden können. Ansonsten wäre es nicht möglich zu überprüfen, ob die Spezifika- 
tion tatsächlich die Absichten des Entwicklers des Systems wiedergibt. Alle Ent- 
wurfsdokumente sollten zudem maschinenlesbar sein, damit sie mit Computern 
verarbeitet werden können. Spezifikationen sollten also in Sprachen festgehalten 
werden, die sowohl von Menschen wie auch von Computern lesbar sind. 
Anfangs können solche Spezifikationen eine natürliche Sprache wie Deutsch, 
Englisch oder Japanisch verwenden. Auch diese natürlichsprachige Beschreibung 
sollte in einem Entwurfsdokument festgehalten werden, damit die resultierende 
Implementierung mit dieser Ausgangsspezifikation verglichen werden kann. Na- 
türliche Sprachen sind aber für spätere Entwurfsphasen unzulänglich, da ihnen 
wichtige Anforderungen an Spezifikationstechniken fehlen: es ist notwendig, Spe- 
zifikationen auf Vollständigkeit und Widerspruchsfreiheit zu prüfen und es sollte 
zudem möglich sein, systematisch Implementierungen aus den Spezifikationen 
ableiten zu können. Natürliche Sprachen erfüllen diese Anforderungen nicht. 
Portierbarkeit und Flexibilität: Spezifikationen sollten unabhängig von der für 
die Implementierung verwendeten spezifischen Hardwareplattform sein, sodass 
man sie leicht für verschiedene Zielplattformen einsetzen kann. Idealerweise 
sollte eine Änderung der Hardwareplattform keinen Einfluss auf die Spezifikation 
haben. Hier müssen im praktischen Einsatz gegebenenfalls kleine Änderungen 
akzeptiert werden. 
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Terminierung: Es sollte möglich sein, anhand der Spezifikation Prozesse zu iden- 
tifizieren, die terminieren. Daher möchten wir Spezifikationen verwenden, für die 
das Halteproblem (das Problem, herauszufinden, ob ein gegebener Algorithmus 
terminieren wird oder nicht, siehe z.B. [494]) entscheidbar ist. 

Unterstützung für Nicht-Standard-Ein/Ausgabegeräte: Viele eingebettete 
Systeme verwenden andere Ein- und Ausgabegeräte als die vom PC her be- 
kannten Tastaturen und Mäuse. Es sollte möglich sein, die Eigenschaften solcher 
Geräte in bequemer Weise zu spezifizieren. 

Nicht-funktionale Eigenschaften: Reale Systeme besitzen eine Reihe nicht- 
funktionaler Eigenschaften, wie etwa Fehlertoleranz, Größe, Erweiterbarkeit, 
Lebenserwartung, Energieverbrauch, Gewicht, Recycling-Fähigkeit, Benutzer- 
freundlichkeit, elektromagnetische Verträglichkeit (EMC) und so weiter. Es ist 
nicht zu erwarten, dass sich all diese Eigenschaften auf eine formale Weise defi- 
nieren lassen. 

Unterstützung für den Entwurf verlässlicher Systeme: Spezifikationstechni- 
ken sollten den Entwurf von verlässlichen Systemen unterstützen. Beispielsweise 
sollte die Spezifikationssprache eine eindeutige Semantik haben und den Ein- 
satz formaler Verifikationstechniken erlauben. Außerdem sollte es möglich sein, 
Anforderungen an Betriebs- und Informationssicherheit zu beschreiben. 

Keine Hürden für die Erzeugung von effizienten Implementierungen: Da 
eingebettete Systeme eflizient sein müssen, sollte die Spezifikationssprache eine 
effiziente Realisierung des Systems nicht behindern oder unmöglich machen. 
Geeignetes Berechnungsmodell (engl. Model of Computation (MoC)): Ein häu- 
fig verwendetes Berechnungsmodell ist das sequenzielle Ausführungsmodell nach 
von Neumann in Kombination mit einem Kommunikationsverfahren. Im MoC 
nach von Neumann sind Spezifikationen üblicherweise in Tasks, Prozesse oder 
Threads gegliedert, die wie folgt definiert werden können: 


Definition 2.2 ([394]): Eine Task kann allgemein definiert werden als „eine 
zugewiesene Menge an Arbeit, die häufig in einer bestimmten Zeit zu erledigen 
ist”. 

Im Kontext von eingebetteten Systemen verstehen wir unter einer Task i.d.R. 
bestimmte Berechnungen, die auszuführen sind. 


Definition 2.3 ([525]): Ein Prozess ist ein in Ausführung befindliches Pro- 
gramm. 


Eine Präzisierung dieses Begriffs wird in der Definition 4.1 gegeben werden. 
Tasks sind teilweise abstrakter beschrieben als die Prozesse, sie sind dann auf 
konkrete Prozesse innerhalb eines Betriebssystems abzubilden. Allerdings wer- 
den die Begriffe Task und Prozess auch teilweise austauschbar benutzt. Eng 
verwandt mit dem Begriff „Prozess” ist der Begriff des Threads. 


Definition 2.4: Ein Thread ist ein „leichtgewichtiger” Prozess. Das bedeutet, 
dass die Umschaltung zwischen der Ausführung von Threads mit weniger Auf- 
wand verbunden ist als bei der Umschaltung zwischen allgemeinen Prozessen. 
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In der Regel können Threads untereinander über einen Zugriff auf gemeinsamen 
Speicher kommunizieren. 


Eine Präzisierung dieses Begriffs wird in der Definition 4.2 gegeben werden. 
Das Modell nach von Neumann weist allerdings besonders für eingebettete Sys- 
teme eine Reihe schwerwiegender Probleme auf, wie z.B.: 


— Es fehlen Möglichkeiten zur Beschreibung von Zeitverhalten. 

— Berechnungen nach dem von-Neumann-Modell basieren implizit auf Zugriffen 
auf globalen gemeinsamen Speicher (wie in Java). Dabei muss der exklusive 
Zugriff auf die gemeinsam verwendeten Ressourcen sichergestellt sein. An- 
sonsten würden Anwendungen mit mehreren Threads, die zu beliebigen Zeiten 
verdrängt werden können, ein nur schwer vorhersagbares Verhalten zur Folge 
haben*. Die Verwendung von Funktionen, die exklusiven Zugriff ermögli- 
chen, kann aber sehr schnell zu Verklemmungen (engl. Deadlocks) führen. 
Diese sind nur schwer zu erkennen und können in einem System viele Jahre 
lang unentdeckt bleiben. 


Beispiel 2.2: Edward Lee [330] zeigt hierzu ein sehr drastisches Beispiel. 
Er analysierte Implementierungen eines einfachen Observer Patterns in Ja- 
va. Dieses erfordert, dass Änderungen eines Wertes von einem Erzeuger an 
eine Menge an angemeldeten Beobachtern weitergeleitet werden. Dieses Ver- 
halten kommt in eingebetteten Systemen sehr häufig vor, ist aber in einer 
von-Neumann-basierten Umgebung mit mehreren verdrängbaren Threads nur 
sehr schwer korrekt zu implementieren. Lee’s Code für eine möglichen Imple- 
mentierung des Observer Patterns in Java in einer Umgebung mit mehreren 
Threads sieht wie folgt aus: 


public synchronized void addListener(listener) {...} 
public synchronized void setValue(newvalue) { 
myvalue=newvalue; 
for (int i=0; i<mylisteners.length; i++) { 
myListeners[i].valueChanged(newvalue) ; 


} 
bi 


Die Methode addListener meldet neue Beobachter an, die Methode setValue 
leitet neue Werte an angemeldete Beobachter weiter. In einer Umgebung mit 
mehreren Threads können normalerweise Threads zu jedem beliebigen Zeit- 
punkt verdrängt werden, was eine nicht vorhersagbare Ausführungsreihenfol- 
ge der Threads zur Folge hat. Das Hinzufügen von Beobachtern, während 
setValue gerade ausgeführt wird, kann zu Komplikationen führen, d.h. wir 
würden nicht wissen, ob der neue Wert bereits den Beobachter erreicht hat. 
Zudem stellt die Menge der Beobachter eine globale Datenstruktur dieser 
Klasse dar. Daher sind diese Methoden synchronisiert, um zu vermeiden, dass 
die Menge der Beobachter geändert wird, während bereits einige Werte wei- 
tergeleitet werden. So kann nur eine der beiden Methoden gleichzeitig aktiv 


* Beispiele dafür sind in den meisten Kursen zu Betriebssystemen zu finden. 


38 


2 Spezifikation und Modellierung 


sein. Dieser gegenseitige Ausschluss ist notwendig, um die unerwiinschte Ver- 
mischung der Ausfiihrung verschiedener Methoden in einer Umgebung mit 
mehreren Threads zu verhindern. Warum ist dieser Code nun problematisch? 
Der Grund dafür ist, dass valueChanged versuchen könnte, exklusiven Zu- 
griff auf eine bestimmte Ressource (z.B. R) zu erhalten. Wenn diese Ressource 
bereits von einer anderen Methode (z.B. A) belegt ist, wird dieser Zugriff ver- 
zögert, bis A die Ressource R freigibt. Wenn nun A die Methode addListener 
oder setValue (möglicherweise indirekt) aufruft, bevor R freigegeben wurde, 
entsteht eine Verklemmung zwischen diesen Methoden: setValue wartet auf 
R, die Freigabe von R erfordert, dass A fortfahren kann, A kann aber nicht 
fortfahren, bevor sein Aufruf der Methode setValue oder setListener zu- 
rückkehrt. Dadurch entsteht die Verklemmung. 

Dieses Beispiel verdeutlicht, dass Verklemmungen als Folge der Verwendung 
mehrerer Threads entstehen können, wenn diese beliebig verdrängt werden 
können und damit gegenseitigen Ausschluss für den Zugriff auf kritische 
Ressourcen benötigen. Lee hat gezeigt [330], dass viele der vorgeschlage- 
nen „Lösungen” des Problems selbst wieder problematisch sind. Also ist auch 
dieses sehr einfache Verhalten in einer von-Neumann-Umgebung mit mehreren 
Threads nur schwer korrekt zu implementieren. Offenbar können Menschen 
Nebenläufigkeit nur sehr schlecht verstehen und es besteht das Risiko, dass 
mögliche Verklemmungen übersehen werden, auch wenn der Code gründlichst 
inspiziert wurde. V 


Lee kam daher zu der drastischen Schlussfolgerung, dass ,,nichttriviale, mit 
Threads, Semaphoren und Mutexen entwickelte Software für Menschen un- 
verständlich ist” und dass „Threads als ein Modell für Nebenläufigkeit nur 
sehr schlecht zu eingebetteten Systemen passen. ... sie funktionieren nur gut 
... wenn best-effort Scheduling-Verfahren ausreichend sind” [333]. 

Die Gründe der Entstehung von Verklemmungen wurden detailliert im Zu- 
sammenhang mit Betriebssystemen untersucht (z.B. in [507]). Es gibt hier 
vier wohlbekannte Bedingungen, die erfüllt sein müssen, damit eine Verklem- 
mung eintreten kann: gegenseitiger Ausschluss, kein Entzug von Ressourcen, 
das Halten von Ressourcen, während auf eine weitere Ressource gewartet 
wird und schließlich die gegenseitige Abhängigkeit von Threads. Das erwähn- 
te Beispiel erfüllt alle vier Kriterien. Die Betriebssystemtheorie stellt keine 
allgemeingültige Lösung für dieses Problem bereit. Seltene Verklemmungen 
mögen bei einem PC annehmbar sein, in sicherheitskritischen Systemen sind 
sie aber keinesfalls akzeptabel. 


Wir möchten nun Systeme so spezifizieren, dass wir uns keine Sorgen um mögli- 
che Verklemmungen machen müssen. Daher erscheint es sinnvoll, Berechnungs- 
modelle zu betrachten, die nicht auf von-Neumann-Prinzipien basieren und damit 
das Problem von Verklemmungen umgehen. Wir beginnen die Betrachtung sol- 
cher Berechnungsmodelle im folgenden Abschnitt. Darin zeigen wir, dass das 
Observer-Muster mit anderen Berechnungsmodellen einfacher korrekt imple- 
mentierbar ist. 
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Die Liste von Anforderungen an Modellierungssprachen lasst erkennen, dass es 
wohl nie eine einzige formale Sprache geben wird, die alle diese Anforderungen 
erfiillt. In der Praxis muss man daher in der Regel mit Kompromissen leben und eine 
Kombination verschiedener Sprachen einsetzen, von der jede fiir die Beschreibung 
eines bestimmten Problemkreises geeignet ist. Die Auswahl der Spezifikationss- 
prache, die für ein bestimmtes Projekt verwendet wird, hängt hauptsächlich vom 
Anwendungsbereich und von der Umgebung, in der das System entwickelt werden 
soll, ab. Wir stellen im Folgenden einige Sprachen vor, die für den Entwurf eines 
praxisnahen Systems in Frage kommen. Diese Sprachen dienen als Beispiele, um die 
wichtigsten Eigenschaften des zugehörigen Berechnungsmodells zu beschreiben. 


2.2 Berechnungsmodelle 


Berechnungsmodelle (engl. Models of Computation (MoCs)) beschreiben Mecha- 
nismen, welche die Durchführung von Berechnungen beschreiben. Im Allgemeinen 
müssen wir dabei von Systemen ausgehen, die aus verschiedenen Komponenten be- 
stehen. Mittlerweile istes üblich, streng zwischen den Berechnungen in den einzelnen 
Komponenten und der Kommunikation zu trennen. Diese Unterscheidung erleich- 
tert die Wiederbenutzung von Komponenten in verschiedenen Kontexten und sie 
ermöglicht ein plug-and-play-Konzept für Systemkomponenten. Dementsprechend 
definieren wir Berechnungsmodelle wie folgt [329, 268, 269, 270]: 


Definition 2.5: Berechnungsmodelle (MoCs) definieren 


e Komponenten und die Organisation des Ablaufs von Berechnungen in diesen 
Komponenten: Prozeduren, Prozesse, Funktionen oder endliche Automaten sind 
mögliche Komponenten. 

e Kommunikationsprotokolle: Diese Protokolle beschreiben die Kommunikati- 
onsmöglichkeiten zwischen den Komponenten. Asynchroner Nachrichtenaus- 
tausch und Rendez-Vous-basierte Kommunikation sind Beispiele für solche Pro- 
tokolle. 


Beziehungen zwischen Komponenten können mit Hilfe von Graphen beschrieben 
werden. In solchen Graphen bezeichnen wir die Berechnungen als Tasks. Die Bezie- 
hungen zwischen Tasks werden wir als Task-Graph und in bestimmten Kontexten 
auch als Prozessnetz bezeichnen. Knoten in Graphen repräsentieren Komponenten, 
die bestimmte Berechnungen ausführen. Die Berechnungen bilden Eingabedatenströ- 
me auf Ausgabedatenströme ab. Sie werden in einigen Fällen in Hochsprachen imple- 
mentiert. Typische Tasks enthalten (möglicherweise nicht-terminierende) Schleifen. 
In jedem Durchlauf einer solchen Schleife lesen sie Daten von ihren Eingängen, 
verarbeiten diese Daten und erzeugen Daten in den Ausgabedatenströmen. Kanten 
beschreiben die Beziehungen zwischen Komponenten. Im Folgenden definieren wir 
diese Graphen nun genauer. 

Die offensichtlichste Beziehung zwischen Tasks ist die kausale Abhängigkeit: 
Viele Berechnungen können erst dann ausgeführt werden, wenn andere Berech- 
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nungen abgeschlossen sind. Solche Reihenfolgebeschränkungen implizieren eine 
Präzedenzrelation und sie werden typischerweise in Abhängigkeitsgraphen als 
Kanten dargestellt. Abb. 2.2 zeigt einen Abhängigkeitsgraph für eine Menge von 


Berechnungen. 
©) 
ee 
BD) 


Definition 2.6: Ein Abhängigkeitsgraph ist ein gerichteter azyklischer Graph (engl. 
Directed Acyclic Graph (DAG)) G = (t, E) mit der Knotenmenge r und der Kan- 
tenmenge E. E C t XT stellt eine Relation auf t dar. Wenn (71,72) € E, dann 
wird 7, ein direkter Vorgänger von T) genannt, entsprechend heißt t2 direkter 
Nachfolger von 7;. Sei nun E* die transitive Hülle von E. Wenn (71,72) € E*, dann 
ist rı Vorgänger von 72 und T? ist Nachfolger von 7. 


Abb. 2.2 Abhängigkeitsgraph 


Solche Abhängigkeitsgraphen sind Spezialfälle von Task-Graphen. Task-Graphen 
können mehr Informationen enthalten als in Abb. 2.2 dargestellt. Beispielsweise kön- 
nen Task-Graphen die Abhängigkeitsgraphen um folgende Eigenschaften erweitern: 


1. Zeit-Informationen: Tasks können Ankunftszeiten, Deadlines, Perioden und 
Ausführungszeiten haben. Um diese graphisch darzustellen, kann es sinnvoll sein, 
sie in den Graphen darzustellen. In diesem Buch werden wir diese Informationen 
aber unabhängig von den Graphen repräsentieren. 

2. Unterscheidung von verschiedenen Beziehungsarten zwischen Berechnungen: 

Präzedenzrelationen modellieren lediglich Reihenfolgebeschränkungen für die 
Ausführung. Auf einer detaillierteren Ebene kann es hilfreich sein, zwischen 
Bedingungen für das Scheduling und für die Kommunikation zwischen Berech- 
nungen zu unterscheiden. Kommunikation kann wieder durch Kanten beschrie- 
ben werden. Es können allerdings weitere Informationen zu jeder dieser Kanten 
bekannt sein, etwa der Zeitpunkt der Kommunikation und die ausgetauschte Da- 
tenmenge. Präzedenzrelationen können als eigene Kantenart betrachtet werden, 
da es Situationen geben kann, in denen Tasks nacheinander ausgeführt werden 
müssen, obwohl sie keine Informationen miteinander austauschen. 
In Abb. 2.2 sind Ein- und Ausgaben (engl. Input/Output (I/O)) nicht explizit 
dargestellt. Implizit wird angenommen, dass Knoten ohne Vorgänger im Graphen 
irgendwann eine Eingabe erhalten. Weiter wird angenommen, dass sie nach einer 
gewissen Zeit eine Ausgabe für den Nachfolgerknoten erzeugen. Diese Ausgabe 
ist erst dann verfügbar, wenn die Berechnung abgeschlossen ist. Es ist oft nützlich, 
Ein- und Ausgaben eindeutiger zu beschreiben. Um dies zu erreichen, wird ein 
weiterer Relationstyp benötigt. Wir verwenden die Notation von Thoen [538], in 
der Kreise mit Punkt Ein- und Ausgaben darstellen, wie in Abb. 2.3 zu sehen. 


2.2 Berechnungsmodelle 41 


Abb. 2.3 Task-Graph mit (e) 
Ein/Ausgabeknoten und 2 


-kanten 
O= D-O 0 


3. Exklusiver Zugriff auf Ressourcen: Berechnungen können einen exklusiven Zu- 
griff auf eine Ressource anfordern, etwa auf ein Ein/Ausgabegerät oder auf einen 
Speicherbereich zur Kommunikation. Informationen über eventuell notwendige 
exklusive Zugriffe sollten beim Scheduling berücksichtigt werden. Durch die 
Verwendung dieser Information kann man z.B. das Problem der Prioritätsum- 
kehr vermeiden (siehe Seite 233). Solche Informationen über exklusiven Zugriff 
können auch in Task-Graphen dargestellt werden. 

4. Periodische Abläufe: Viele Berechnungen, insbesondere im Bereich der digita- 
len Signalverarbeitung, sind periodisch. Man muss also genauer zwischen einer 
Task und ihrer Ausführung unterscheiden - letztere wird häufig als Job bezeich- 
net [349]°. Task-Graphen für solche Schedules sind unendlich groß. Abb. 2.4 
zeigt einen Task-Graphen mit den Jobs J„-ı bis J„+1 einer periodischen Task. 


Abb. 2.4 Task-Graph mit 
Jobs (Ausführungen) einer 
periodischen Task 


In-1 Jn Jn+1 < 


5. Hierarchische Knoten: Die Komplexität der Berechnungen, die in einem Kno- 
ten ausgeführt werden, kann sehr unterschiedlich sein. Einerseits können die 
beschriebenen Programme sehr groß sein und Tausende von Codezeilen enthal- 
ten. Andererseits kann man Programme in kleine Programmteile aufteilen, sodass 
im Extremfall jeder Knoten nur genau einer Operation entspricht. Die Komplexi- 
tät von Knoten im Graphen heißt Granularität. Die Frage, welche Granularität 
man verwenden sollte, lässt sich nicht allgemeingültig beantworten. Für einige 
Zwecke sollte die Granularität so grob wie möglich sein, etwa wenn die Knoten 
Prozesse eines Echtzeitbetriebssystems darstellen. In diesem Fall sollten die Kno- 
ten große Programmteile enthalten, um die Anzahl der Kontextwechsel zwischen 
den Prozessen gering zu halten. Für andere Anwendungen kann es sinnvoll sein, 
wenn jeder Knoten nur eine Operation enthält, etwa wenn die Knoten entweder 
als Hardware oder als Software realisiert werden sollen. Wenn eine bestimm- 
te Operation (z.B. die häufig vorkommende Diskrete Cosinus-Transformation 
(DCT)) auf eine Spezialhardware abgebildet werden kann, dann sollte sie nicht 
in einem großen Knoten mit vielen anderen Operationen versteckt sein. Vielmehr 


5 Präzisierungen erfolgen in den Definitionen 4.4 und 6.1. 
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sollte die DCT als einzelner Knoten modelliert werden. Hierarchische Knoten 
helfen dabei, häufige Wechsel der Granularität zu vermeiden. Auf einer hohen 
Hierarchieebene können die Knoten dann z.B. komplexe Aufgaben beschreiben, 
auf einer niederen Ebene Basisblöcke® oder auf einer noch niedrigeren Ebene 
einzelne arithmetische Operationen. Abb. 2.5 zeigt eine hierarchische Version 
des Abhängigkeitsgraphen aus Abb. 2.2, in dem ein hierarchischer Knoten durch 
ein Rechteck dargestellt wird. 


Abb. 2.5 Hierarchischer Task-Graph (%) 


Wie oben beschrieben, lassen sich Berechnungsmodelle anhand der Kommunika- 


tionsmodelle (dargestellt durch Kanten im Task-Graphen) und der Berechnungsmo- 
delle innerhalb der Komponenten (dargestellt durch die Knoten des Task-Graphen) 
klassifizieren. Im Folgenden führen wir einige bekannte Beispiele für Berechnungs- 
modelle auf: 


Kommunikationsmodelle: Wir unterscheiden zwischen zwei Kommunikations- 
paradigmen: Gemeinsamer Speicher und Nachrichtenaustausch. Weitere exis- 
tierende Kommunikationsmodelle (wie z.B. verschränkte Zustände in der Quan- 
tenmechanik [62]) werden in diesem Buch nicht betrachtet. 


— Gemeinsamer Speicher (engl. shared memory) 


Bei diesem Modell greifen kommunizierende Komponenten auf gemeinsamen 
Speicher zu. Zugriffe auf gemeinsamen Speicher sollten geschützt werden, so- 
lange nicht ausschließlich Lesezugriffe erfolgen. Sobald ein Schreibzugriff 
verwendet wird, muss exklusiver Zugriff auf den Speicher für alle beteiligten 
Komponenten garantiert werden. Die Programmabschnitte, die den exklusi- 
ven Zugriff benötigen, werden kritische Abschnitte genannt (siehe auch Lee’s 
Beispiel 2.2). Zu den Methoden, die exklusiven Zugriff sicherstellen, gehören 
Semaphore, bedingte kritische Abschnitte und Monitore. Die einzelnen Tech- 
niken sind im Detail in Betriebssystem-Lehrbüchern, wie z.B. von Stallings 
[507], beschrieben. Kommunikation über gemeinsamen Speicher kann sehr 
schnell sein. Allerdings ist die Implementierung für Multiprozessor-Systeme 
schwierig zu realisieren, wenn kein physikalisch gemeinsamer Speicher vor- 
handen ist und dieser daher simuliert werden muss. 


6 Basisblöcke sind Codeblöcke von maximaler Länge, die — außer möglicherweise an ihrem Ende — 
keinen Sprungbefehl enthalten und in die nicht von anderen Codeblöcken aus hinein verzweigt 


wird. 


2.2 Berechnungsmodelle 43 


— Nachrichtenaustausch (engl. message passing): Beim Nachrichtenaustausch 
kommunizieren Prozesse durch das Versenden von Nachrichten miteinander. 
Diese Methode lässt sich auch dann einfach implementieren, wenn kein ge- 
meinsamer Speicher zur Verfügung steht. Allerdings ist Nachrichtenaustausch 
meist langsamer als Kommunikation über gemeinsamen Speicher. Für diese 
Kommunikationsmethode wird zwischen den folgenden drei Techniken unter- 
schieden: 

Beim asynchronen Nachrichtenaustausch, auch nicht-blockierende Kom- 
munikation genannt, kommunizieren die Komponenten durch Senden von 
Nachrichten über Kanäle, die Nachrichten puffern können. Der Sender muss 
also nicht warten, bis der Empfänger bereit ist, die Nachricht zu empfangen. 
Dies entspricht dem Versenden eines Briefs oder einer Email. Hier kann 
potenziell das Problem auftreten, dass die Nachrichten gespeichert werden 
müssen und die Nachrichtenpuffer überlaufen können. Verschiedene Spra- 
chen, wie z.B. SDL (siehe Seite 68) und SDF (siehe Seite 78), nutzen diese 
Kommunikationsmethode. 

Bei synchronem Nachrichtenaustausch, auch blockierende Kommuni- 
kation oder Rendez-Vous-Kommunikation genannt, kommunizieren die 
Komponenten mittels atomarer, unverzögerter Aktionen, die Rendez-Vous 
genannt werden. Derjenige Kommunikationspartner, der die entsprechende 
Codestelle zuerst erreicht, muss auf den anderen Partner warten. Dies ent- 
spricht einem Treffen oder einem Telefonanruf. Beispiele hierfür sind CSP 
(siehe Seite 122) und Ada (siehe Seite 123). 

Erweitertes Rendez-Vous (auch entfernter Methodenaufruf) erweitert die 
Rendez-Vous-Kommunikationsmethode dahingehend, dass der Sender nur 
dann mit seiner Programmausführung fortfahren darf, wenn eine Bestä- 
tigung für die versendete Nachricht erhalten wurde. Der Empfänger muss 
diese Nachricht aber nicht unmittelbar nach Empfang der Nachricht senden, 
vielmehr kann er z.B. die empfangenen Nachrichteninhalte vor dem Senden 
der Bestätigung überprüfen und, falls erforderlich, bei Fehlern eine andere 
Antwort senden. 


e Organisation von Berechnungen innerhalb der Komponenten: 


— Differentialgleichungen: Mit Differentialgleichungen lassen sich analoge 
Schaltkreise und physikalische Systeme modellieren. Damit finden sie An- 
wendung in der Modellierung cyber-physikalischer Systeme. 

— Endliche Automaten (engl. Finite State Machines (FSMs)): Dieses Modell 
basiert auf einer endlichen Menge von Zuständen, Ein- und Ausgaben sowie 
Transitionen zwischen Zuständen. Es kann vorkommen, dass mehrere endli- 
che Automaten kommunizieren müssen, diese bilden dann kommunizierende 
endliche Automaten (engl. Communicating Finite State Machines (CFSMs)). 

— Datenfluss: Im Datenflussmodell triggert die Verfiigbarkeit von Daten (d.h. 
der Operanden) die Ausführung von Operationen. 

— Diskretes Ereignismodell: In diesem Modell tragen alle Ereignisse einen 
vollständig geordneten Zeitstempel, der die Zeit angibt, zu der das Ereig- 
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nis stattfindet. Simulatoren für diskrete Ereignismodelle verfügen über eine 
nach der Zeit sortierte globale Ereigniswarteschlange. Einträge in der Warte- 
schlange werden in genau dieser Reihenfolge abgearbeitet. Der Nachteil dieses 
Modells ist, dass es auf globalen Ereigniswarteschlangen basiert. Dies macht 
es schwierig, das semantische Modell auf parallele Implementierungen abzu- 
bilden. Beispiele sind u.a. SystemC (siehe Seite 107), VHDL (siehe Seite 109) 
und Verilog (siehe Seite 120). 

— Von-Neumann-Modell: Dieses Modell basiert auf der sequenziellen Ausfüh- 
rung von Folgen einfacher Berechnungsoperationen. 


Kombinierte Modelle: Real existierende Sprachen verbinden meist ein bestimm- 
tes Kommunikationsmodell mit einem Modell der Berechnungen in den Kom- 
ponenten. So kombiniert StateCharts (siehe Seite 55) endliche Automaten mit 
gemeinsamem Speicher, SDL (siehe Seite 68) verbindet endliche Automaten für 
die Berechnung in den Komponenten mit asynchronem Nachrichtenaustausch für 
die Kommunikation. Ada (siehe Seite 123) und CSP (siehe Seite 122) kombinieren 
das Modell der von-Neumann-Befehlsausführung mit synchronem Nachrichten- 
austausch. Tabelle 2.1 gibt einen Überblick über die in diesem Kapitel behandelten 
kombinierten Modelle. Diese Tabelle führt für die meisten Berechnungsmodelle 
auch eine Beispielsprache auf. 


Tabelle 2.1 Überblick über betrachtete Berechnungsmodelle und Sprachen 


Kommunikation/Organi- |Gemeinsamer Speicher Nachrichtenaustausch 

sation der Komponenten |(shared memory) synchron | asynchron 

Undefinierte Text oder Grafik, Anwendungsfälle (use cases) 

Komponenten (Message) sequence charts 

Differentialgleichungen Modelica, Simulink®, VHDL-AMS 

Kommunizierende StateCharts SDL 

endliche Automaten 

(CFSMs) 

Datenfluss Scoreboarding, Kahn-Netzwerke 
Tomasulo-Algorithmus SDF 

Petrinetze C/E-Netze, P/T-Netze, ... 

Diskrete Ereignis (DE)- VHDL, Verilog, (Nur experimentelle Systeme) 

Modelle * SystemC Verteilte DE in Ptolemy 

Von-Neumann- C, C++, Java C, C++, Java, ... mit Bibliotheken 

Modell CSP, Ada 


* Die Klassifikation von VHDL, Verilog und SystemC basiert auf deren Implementierung in Si- 
mulatoren. Nachrichtenaustausch kann in diesen Sprachen auf dem Simulationskern aufbauend 
implementiert werden. 


Unter den Sprachen mit einem definierten Berechnungsmodell finden wir für 


Differentialgleichungen als Beispiele die Sprachen Modelica [400], Simulink® [533] 
und die Erweiterung der Hardwarebeschreibungssprache VHDL zu VHDL-AMS 
[246]. 
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Scoreboarding und der Tomasulo-Algorithmus sind Datenfluss-getriebene Be- 
rechnungsmodelle für das dynamische Scheduling in der Rechnerarchitektur. Sie 
werden in den Rechnerarchitektur-Büchern von Hennessy und Patterson [212] be- 
schrieben und sind nicht Teil dieses Buches. 

Jedes der Berechnungsmodelle hat Vor- und Nachteile für bestimmte Anwen- 
dungsgebiete. Es kann daher schwierig sein, das „beste”” Berechnungsmodell für eine 
bestimmte Anwendung zu wählen. Eine Möglichkeit zur Vereinfachung der Auswahl 
ist es, Berechnungsmodelle zu kombinieren (wie z.B. in Ptolemy [460, 120]). Mo- 
delle können auch aus einem Berechnungsmodell in ein anderes überführt werden. 
Nicht-von-Neumann-Modelle werden häufig in von-Neumann-Modelle übersetzt. 
Die Unterschiede zwischen den einzelnen Modellen verschwimmen, wenn es einfa- 
che Möglichkeiten gibt, sie ineinander umzuwandeln. 

Entwürfe, die von nicht-von-Neumann-Modellen ausgehen, werden oft modell- 
basierte Entwürfe genannt [422]. Der grundlegende Gedanke hinter dem modell- 
basierten Entwurf ist es, ein abstraktes Modell des zu entwerfenden Systems zu 
erstellen. Die Eigenschaften des Systems können dann auf dieser Abstraktionsebene 
analysiert werden, ohne sich mit konkreter Software befassen zu müssen. Software 
wird erst generiert, nachdem das Verhalten des Modells genau analysiert wurde, 
diese Software wird dann automatisch erzeugt [477]. Der Begriff „modellbasierter 
Entwurf” ist allerdings nicht genau definiert. Er wird meist mit Modellen von Re- 
gelungssystemen verbunden, die Komponenten herkömmlicher Regelungssysteme 
wie Integratoren, Differentiatoren usw. enthalten. Diese Sichtweise erscheint aber 
zu sehr eingeschränkt, da wir z.B. auch mit einem abstrakten Modell eines Geräts 
aus dem Bereich der Konsumelektronik beginnen könnten. 

Im Folgenden stellen wir verschiedene Berechnungsmodelle vor und verwenden 
dabei existierende Sprachen zur Beschreibung ihrer Eigenschaften. Edwards [147] 
gibt einen ähnlichen (aber kürzeren) Überblick über dieses Thema. Eine ausführli- 
chere Abhandlung ist in [187] zu finden. 


2.3 Frühe Entwurfsphasen 


Die anfänglichen Gedanken zu einem System werden meist sehr formlos festge- 
halten, vielleicht auf einem Blatt Papier. Meist existieren in dieser frühen Phase 
des Entwurfs dabei nur Beschreibungen des Systems in einer natürlichen Sprache 
wie Englisch oder Japanisch. Diese oft sehr informellen Beschreibungen sollten in 
maschinenlesbarer Form erfasst werden, beispielsweise mit einer Textverarbeitung, 
und dann durch ein Verwaltungswerkzeug gespeichert werden. Ein gutes Werkzeug 
könnte dabei Verbindungen zwischen den Anforderungen modellieren sowie eine 
Abhängigkeitsanalyse und eine Versionsverwaltung anbieten. DOORS® [229] ist 
ein Beispiel solcher Werkzeuge. 


46 2 Spezifikation und Modellierung 


2.3.1 Anwendungsfälle 


Für viele Entwürfe ist es nützlich, Wissen über die potenziellen Verwendungsmög- 
lichkeiten des Systems nutzen zu könnnen. Dieses Wissen wird in Anwendungsfäl- 
len (engl. use cases) festgehalten. Anwendungsfälle beschreiben mögliche Anwen- 
dungen des Systems; hierfür können unterschiedliche Darstellungsarten zum Einsatz 
kommen. 

Das Ziel des UML-Standards [435, 166, 208] ist es, einen systematischen Ansatz 
für die ersten Spezifikationsphasen zu bieten. UML steht für „Unified Modeling 
Language” und wurde von führenden Softwareexperten entwickelt. Die verfügbaren 
kommerziellen Werkzeuge dienen hauptsächlich der Unterstützung des Softwareent- 
wurfsprozesses. UML stellt dafür eine standardisierte Form von Anwendungsfällen 
zur Verfügung. 

Anwendungsfälle besitzen weder ein genau spezifiziertes Berechnungsmodell 
noch ein präzise spezifiziertes Kommunikationsmodell. Häufig wird behauptet, dies 
sei eine absichtliche Einschränkung, um zu vermeiden, dass sich Entwickler in den 
frühen Entwurfsphasen zu viele Gedanken über Details machen. 


Beispiel 2.3: In Abb. 2.6 sind einige Anwendungsfälle für einen Anrufbeantworter 
zu sehen’. Es gibt fünf Anwendungsfälle für den Eigentümer des Anrufbeantworters 
und einen für einen potentiellen Anrufer. Wir müssen sicherstellen, dass alle sechs 
Fälle richtig implementiert werden. 


Spiele nächste Nachricht > 
Lösche letzte Nachricht > 
Lösche alle Nachrichten > 
Anrufer 


Schalte Anrufbeantworter an > T 


Schalte Anrufbeantworter aus > 


Benutzer 


<_BegrtiBung+Piep+Nachricht 


Abb. 2.6 Beispiel fiir Anwendungsfalle Vv 


Anwendungsfälle ermöglichen es, verschiedene Klassen von Benutzern und An- 
wendungen, die das System unterstützen soll, voneinander zu unterscheiden. So ist 
es möglich, die Erwartungen an ein System auf sehr abstrakter Ebene festzuhalten. 


7 Wir gehen davon aus, dass UML ausführlich in einer Vorlesung über Software-Engineering 
behandelt wird. Daher wird das Thema UML in diesem Buch nur kurz angerissen. 
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2.3.2 (Message) Sequence Charts 


Wenn eine etwas detailliertere Betrachtungsweise gewünscht ist, können die zwi- 
schen den einzelnen Komponenten ausgetauschten Nachrichtenfolgen angegeben 
werden. Diese werden benötigt, um eine bestimmte Art der Verwendung des Sys- 
tems zu realisieren. Sequence charts (SCs) — früher auch message sequence charts 
(MSCs) genannt — ermöglichen dies. Sequence charts verwenden ein zweidimen- 
sionales Diagramm. In einer Dimension (üblicherweise in der Vertikalen) werden 
Abfolgen dargestellt, während die verschiedenen Kommunikationskomponenten in 
der zweiten Dimension angeordnet sind. SCs beschreiben Teilordnungen von Nach- 
richtenübertragungen. Sie beschreiben damit ein mögliches Systemverhalten. 

SCs sind als Teil von UML standardisiert. Im Vergleich zu UML 1.0 wurden SCs 
in UML 2.0 durch Elemente erweitert, die genauere Beschreibungen ermöglichen. 


Beispiel 2.4: Abb. 2.7 zeigt einen der Anwendungsfälle des Anrufbeantworters. Ge- 


Anrufer ‘Telefon :Anrufbeantworter 


Nummer eingeben | 


Anruf anzeigen 


Annahme anzeigen | | warten 


Begrüßung l- Sende Begrüßung 

Piep Piep übertragen 
Ss 

Nachricht 


Nachricht übertragen 


Hörer auflegen 


Rufende anzeigen a 


Kommunikation mit einem Anrufbeantworter 


Abb. 2.7 Anrufbeantworter in UML™ 


strichelte Linien sind sogenannte ‚life lines” (Lebenslinien). Die Abfolge der Nach- 
richten entspricht ihrer Reihenfolge entlang der Lebenslinie. Bei diesem Beispiel 
gehen wir davon aus, dass alle Informationen in Form von Nachrichten versendet 
werden. Die Pfeile im Diagramm stehen für asynchrone Nachrichten. Damit kann 
ein Sender mehrere Nachrichten hintereinander aussenden, ohne auf eine Bestäti- 
gung warten zu müssen. Die Rechtecke oberhalb der Lebenslinien stellen die jeweils 
aktive Komponente dar. Im Beispiel wartet der Anrufbeantworter darauf, dass der 
Benutzer den Hörer des Telefons innerhalb einer bestimmten Zeit abnimmt. Wenn 
dies nicht geschieht, nimmt der Anrufbeantworter selbst das Gespräch an und spielt 
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eine Begrüßungsnachricht ab. Daraufhin kann der Anrufer seine Nachricht hinterlas- 
sen. Alternative Abläufe (z.B. das vorzeitige Beenden des Anrufs, weil der Anrufer 
auflegt oder der Fall, dass der Angerufene das Telefon abnimmt) sind hier nicht 
dargestellt. V 


Komplexe kontrollflussabhängige Vorgänge lassen sich mit SCs nicht darstel- 
len. Hierfür müssen andere Berechnungsmodelle verwendet werden. Oft müssen 
bestimmte Vorbedingungen erfüllt sein, damit SCs angewendet werden können. 
Live Sequence Charts [118] beinhalten Methoden zur Beschreibung solcher Vorbe- 
dingungen. Zudem verfügen sie über die Möglichkeit, zwischen notwendigen und 
optionalen Folgen zu unterscheiden und enthalten einige andere Erweiterungen. 

Weg-Zeit-Diagramme (engl. Time Distance Diagrams (TDDs) oder auch Di- 
stance Time Diagrams) sind eine oft verwendete Variante von SCs. Die zeitliche 
Dimension von TDDs stellt nicht nur logische Abfolgen sondern real ablaufende 
Zeit dar, häufig auch horizontal aufgetragen. In einigen Varianten modelliert die 
räumliche Dimension auch den geographischen Abstand zwischen den Komponen- 
ten. TDDs sind gut geeignet, um Fahrpläne von Verkehrsmitteln darzustellen. 


Beispiel 2.5: Abb. 2.8 zeigt ein Weg-Zeit-Diagramm, mit der Zeit als vertikaler 
Dimension. Es bezieht sich auf Züge, die zwischen Amsterdam, Köln, Brüssel und 
Paris verkehren. Die Züge können entweder von Köln oder von Amsterdam über 
Brüssel nach Paris fahren. Aachen ist als zusätzlicher Halt auf der Strecke zwischen 


Köln Aachen Amsterdam Brüssel Paris 


Ve 


Abb. 2.8 Weg-Zeit-Diagramme 


Köln und Brüssel dargestellt. Vertikale Segmente zeigen die Zeit, die der Zug in 
einem Bahnhof verbringt. In Brüssel gibt es eine zeitliche Überlappung zwischen den 
Zügen aus Richtung Köln und aus Richtung Amsterdam. Es gibt einen zweiten Zug 
zwischen Paris und Köln, der keine Beziehung zu einem Zug von/nach Amsterdam 
hat. Dieses und weitere Beispiele lassen sich mit dem Simulationswerkzeug levi 
simulieren [498]. V 
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Beispiel 2.6: Ein komplexeres und realistischeres Beispiel ist in Abb. 2.9 darge- 
stellt. Es beschreibt den Zugverkehr im Bereich des Schweizer Lötschbergs [225]. 


á re an 


Ç 


Abb. 2.9 Zugverkehr am Lötschberg (mit freundlicher Genehmigung durch N. Huerlimann, Open- 
Track Railway Technology GmbH, © OpenTrack Railway Technology GmbH) 


Die Namen verschiedener Bahnhöfe sind in der Horizontalen gezeigt. Die vertika- 
le Dimension entspricht der Zeit. Schnelle und langsame Züge können anhand der 
Steigung der Linien unterschieden werden. Bei langsamen Zügen ist die Steigung 
groß und enthält möglicherweise sogar vertikale Segmente, was einem Aufenthalt im 
Bahnhof entspricht. Bei schnellen Zügen sind die Linien fast horizontal. Die Züge 
halten jeweils nur an einigen der Bahnhöfe. In dem gezeigten Beispiel ist es nicht 
ersichtlich, ob Überlappungen an Bahnhöfen zufällig erfolgen oder ob eine echte 
Synchronisation fiir Umsteigeverbindungen benötigt wird. Außerdem sind zulässige 
Abweichungen nicht ersichtlich. V 


SCs und TDDs werden in der Praxis sehr häufig verwendet. Sie sind z.B. für 
Anwendungen des Internets der Dinge sehr wichtig. SCs enthalten im Unterschied zu 
TDDs keine Information über physikalische Zeiten. TTDs können dagegen zeitliche 
Abläufe darstellen, geben aber keine genauen Aussagen zur Synchronisation. 

UML wurde ursprünglich nicht für Echtzeitanwendungen entworfen. UML 2.0 
enthält Zeitdiagramme, welche die Angabe der realen Zeit erlauben. Diese Dia- 
gramme erlauben Bezüge zu physikalischen Zeiten, ähnlich wie TDDs. Bestimmte 
UML-,Profile” (siehe Seite 134) stellen zusätzliche Annotationen für Zeitangaben 
zur Verfügung [369]. 
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2.3.3 Differentialgleichungen 


Differentialgleichungen können in der Sprache der Mathematik beschrieben werden. 
Varianten davon können als Eingabe für Entwurfswerkzeuge genutzt werden, die 
entsprechende Modelle unterstützen. Als Beispiel für eine solche Variante nutzen 
wir Modelica [400], eine Sprache, die auf die Modellierung cyber-physikalischer 
Systeme zielt. Modelica besitzt sowohl eine graphische wie auch eine textuelle Dar- 
stellungsform. Mit der graphischen Form kann man Systeme als Menge verbundener 
Blöcke beschreiben. Jeder Block wiederum kann durch Gleichungen modelliert wer- 
den. Verbindungen zwischen den Blöcken symbolisieren gemeinsame Variablen im 
Sinne der Mathematik. Die Informationen zu jedem der Blöcke können zusammen 
mit der Information zu Verbindungen in ein globales Gleichungssystem transformiert 
werden. Dieser Vorgang kann als „flachklopfen” (engl. flattening) der Hierarchie be- 
zeichnet werden. Wie in der Mathematik haben Gleichungen (und Verbindungen) 
eine bidirektionale Bedeutung. 


Beispiel 2.7: Das nachfolgende Modell stellt den springenden Ball dar, der auf Seite 
12 vorgestellt wurde: 


model StickyBall 
type Height = Real(unit = "m"); 
type Velocity = Real(unit = "m/s"); 
parameter Real s = 0.8 "Restitution"; 
parameter Height hð = 1.0 "Initial height"; 
constant Velocity eps = 1e-3 "small velocity"; 
Boolean stuck; 
Height h; 
Velocity v; 
initial equation 
v ð; 
h = hð; 
stuck = false; 
equation 
v = der(h); 
der(v) = if stuck then @ else -9.81; 
when h <= 0.0 then 
stuck = abs(v) < eps; 
reinit(v, if stuck then ð else -sxv); 
end when; 
end StickyBall; 


Im Gleichungsteil wird die Geschwindigkeit v als Ableitung der Hohe h definiert. 
Die Ableitung der Geschwindigkeit wird gleich der Erdbeschleunigung gesetzt, so- 
lange der Ball noch nicht auf der Oberfläche klebt. Für diese Gleichungen gibt 
es Anfangs- bzw. Randbedingungen im initial equation Teil. Die mathemati- 
schen Gleichungen können numerisch integriert werden. Diese Prozedur wird in der 
Beschreibung des Abprallens des Balls ausgenutzt: when-Klauseln können benutzt 


8 Dieses Modell wurde aus einem Modell von Tiller [541] abgeleitet. 
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werden, um Ereignisse auszulösen, die während der Berechnung auftreten. Im Bei- 
spiel wird ein Ereignis ausgelöst, wenn die Höhe des Balls gleich Null oder kleiner 
wird. Wenn dieses Ereignis ausgelöst wird und wenn die Geschwindigkeit noch groß 
genug ist, dann wird die Geschwindigkeit invertiert und aufgrund des Modells des 
teilelastischen Stoßes um die Stoßzahl s reduziert. Die reinit-Klausel definiert eine 
weitere Randbedingung. 

Wenn allerdings die Geschwindigkeit kleiner als eps ist, nehmen wir an, dass der 
Ball klebt und die Geschwindigkeit wird auf Null gesetzt, wodurch alle künftigen 
Aktivitäten unterdrückt werden. Das resultierende Modell kann beispielsweise mit 
OpenModelica? simuliert werden. 

Das Weg-Zeit-Diagramm des Balls kann wie folgt berechnet werden: nach dem 
Loslassen aus der Anfangshöhe fällt der Ball mit einer gleichmäßig beschleunigten 
Bewegung und besitzt dabei zur Zeit t die folgende Geschwindigkeit und die folgende 
zurückgelegte Wegstrecke: 


v=gt (2.1) 
§ 2 

=2t 22 

7 (2.2) 


Dies gilt bis der Ball bei x = ho den initialen Stoß erfährt (O-te Reflektion). Wir 
nennen die dazugehörige Zeit to und die Geschwindigkeit vo. Aus den Gleichungen 
(2.1) und (2.2) ergeben sich 


vo = gto (2.3) 
§ 2 
ho = z% (2.4) 
und daraus 
= (2.5) 
E 
2 
to = 4|— ho (2.6) 
8 


vo = v2gho (2.7) 
Nach dem Stoß steigt der Ball in die Höhe und besitzt dabei die Geschwindigkeit 
v=-svo+gt (2.8) 


bis er die Geschwindigkeit 0 erreicht. Die Zeit bis dahin nennen wir tj. Aus der 
Gleichung (2.8) folgt 
0=-svo+gti bzw. 


t=s— (2.9) 
8 


? Siehe https://openmodelica.org/. 
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Danach fällt der Ball wieder nach unten und benötigt dabei dieselbe Zeit, wie fiir 
das Steigen. Damit erfolgt der nächste Stoß zu einer Zeit 


vo 


ty = = 2s (2.10) 
g 


nach dem initialen Stoß. 

Aus der Rechnung ist zu sehen, dass die Zeit für das Steigen oder das Fallen 
aufgrund der Teilelastizität jeweils um den Faktor s kürzer ist als für das Steigen 
oder Fallen in der vorherigen Iteration. Daher ereignet sich die Reflexion n > 0 
jeweils zum Zeitpunkt 


2 2 
=< ys cea (2.11) 
E ko & 


Unter der Voraussetzung s < 1 konvergiert diese geometrische Reihe gemäß der 
Theorie konvergenter Reihen zu 


2vo $h k VO 2vo vo 
trinat = lim — > -2 = - (2.12) 
n>% g 2, g 8&l-s) 8 


Dies bedeutet: auch wenn der Ball nicht klebrig ist, gibt es eine obere Schranke für 
die Zeitpunkte der Reflexionen. Es gibt dann aber keine Schranke für die Anzahl 
der Reflexionen. Dies entspricht der aus der Mathematik bekannten Tatsache, dass 
unendliche Reihen zu einem endlichen Wert konvergieren können!°. 

Die Benutzung von Gleichungen einschließlich Ableitungen in Modelica bringt 
uns in die Nähe der Sprache der Mathematik und der Physik. Mit der Einführung 
von Ereignissen erhalten wir allerdings wieder sequentielles Verhalten. Die implizite 
numerische Integration führt auch zum Risiko von Problemen mit der numerischen 
Genauigkeit. Dementsprechend wurde auch die Formulierung h <= 0.0 gewählt, 
da wir aufgrund von Genauigkeitsproblemen den Fall h = 0.0 verpassen können. 
Genauigkeitsprobleme gibt es auch für das publizierte Modell des nicht-klebrigen 
Balls [541]: aufgrund beschränkter Genauigkeit liefert Openmodelica eine Lösung, 
bei welcher der Ball bei großen Zeiten t den Boden durchquert! Dieses Problem 
wird dadurch verursacht, dass für sehr kurze Abstände zwischen den Reflexionen 
keine Ereignisse erzeugt werden. 

Dieses Beispiel zeigt sehr schön die Vorteile und Einschränkungen von Mode- 
lica: auf der einen Seite kann man mit Modelica sogar den physikalischen Anteil 
cyber-physikalischer Systeme modellieren. Auf der anderen Seite benutzen wir nicht 
genau die Sprache der Mathematik, was zu möglichen Modellierungsproblemen 
beispielsweise aufgrund numerischer Ungenauigkeiten führt. V 


10 Auf dieser Tatsache ist das Paradoxon von Achilles und der Schildkröte [585] aufgebaut, das 
ebenfalls über eine konvergierende unendliche Reihe modelliert werden kann. 
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2.4 Kommunizierende endliche Automaten 


In den nachfolgenden Abschnitten werden wir nur digitale Systeme betrachten. Ver- 
glichen mit den frühen Entwurfsphasen benötigen wir genauere Modelle unseres zu 
entwerfenden Systems. Auf den Seiten 18 und 34 haben wir bereits erwähnt, dass wir 
zustandsorientiertes Verhalten beschreiben müssen. Klassisch werden dazu endliche 
Automaten (kurz Automaten, engl. Finite State Machines (FSMs)) verwendet, die 
über eine Zustandsmenge, ein Eingabealphabet, Ausgaben sowie die Berechnung 
des Folgezustands modelliert werden. Abb. 2.10 (identisch zu Abb. 2.1) zeigt eine 
graphische Darstellung als klassisches Zustandsdiagramm. 


Abb. 2.10 Zustandsdiagramm 
eines Automaten 


Zustände werden durch Kreise gekennzeichnet. Wir betrachten hier nur Auto- 
maten, die sich jederzeit in genau einem der möglichen Zustände befinden. Solche 
Automaten werden deterministisch genannt. Die Kantenbeschriftung stellt Ereig- 
nisse dar. Angenommen, ein Automat befindet sich in einem bestimmten Zustand 
und es tritt ein Ereignis ein, das einer der von diesem Zustand ausgehenden Kan- 
ten entspricht. Dann geht der Automat über in den Zustand, der sich am Ende der 
Kante befindet. Automaten können implizit getaktet sein. Solche Automaten werden 
synchrone Automaten genannt. Bei diesen finden Zustandsübergänge nur bei Takt- 
übergängen statt. Automaten können auch Ausgaben erzeugen (in Abb. 2.10 nicht 
dargestellt). Weitere Informationen über klassische Automaten finden sich z.B. bei 
Kohavi [302]. 


2.4.1 Zeitgesteuerte Automaten 


Klassische Automaten verfügen über keinerlei Möglichkeiten, Zeit zu modellie- 
ren. Sie wurden daher um eine Möglichkeit ergänzt, Zeitinformationen darzustellen. 
Zeitgesteuerte Automaten (engl. timed automata) sind Automaten, die durch reelle 
Variablen erweitert werden. „Die Variablen modellieren die logischen Uhren des 
Systems. Diese werden beim Systemstart mit Null initialisiert und laufen dann syn- 
chron. An den Kanten angegebene Zeitbeschränkungen schränken das Verhalten des 
Automaten ein. Ein Übergang über eine Kante kann stattfinden, wenn der aktuelle 
Zeitwert der Uhr dem an der Kante angegebenen entspricht. Uhren können bei einer 
Transition auf Null zurückgesetzt werden” [44]. 
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Beispiel 2.8: Abb. 2.11 zeigt ein Beispiel fiir einen zeitgesteuerten Automaten. Der 
Anrufbeantworter befindet sich normalerweise im links dargestellten Anfangszu- 
stand. 


return hand-set 


Abb. 2.11 Bearbeitung ankommender Anrufe bei einem Anrufbeantworter 


Wenn ein Anruf ankommt, wird die Uhr x auf 0 zurückgesetzt und der Automat 
wechselt in den Wartezustand wait. Wenn der Angerufene den Anruf annimmt, kann 
ein Gespräch stattfinden, bis der Hörer aufgelegt wird. Ansonsten kann ein Übergang 
zum Zustand play text stattfinden, wenn die Zeit den Wert 4 erreicht hat. 

Sobald der Übergang stattgefunden hat, wird eine aufgezeichnete Nachricht abge- 
spielt und mit einem Piepton beendet. Die Uhr y garantiert, dass der Ton mindestens 
eine Zeiteinheit lang ist. Danach wird die Uhr x wieder auf 0 zurückgesetzt und der 
Anrufbeantworter beginnt mit der Aufnahme. Wenn die Zeit den Wert 8 erreicht 
hat oder der Anrufer nichts sagt, Kann der nächste Piepton abgespielt werden, der 
auch wieder mindestens eine Zeiteinheit dauert. Danach findet ein Übergang in den 
Schlusszustand statt. In diesem Beispiel werden Übergänge durch Eingaben (wie 
lift-off) oder durch Uhren-Einschränkungen (engl. clock constraints) ausgelöst. V 


Zeitbedingungen beschreiben Übergänge, die stattfinden können, aber nicht müs- 
sen. Um sicherzustellen, dass ein Übergang wirklich stattfindet, können zusätzlich 
Stelleninvarianten (engl. location invariants) definiert werden. Die Stelleninvari- 
anten x < 5, x < 9 und y < 2 werden im Beispiel verwendet, damit Transitionen 
spätestens eine Zeiteinheit nach der sie auslösenden Bedingung aktiv werden. Im 
Beispiel dienen zwei Uhren der Veranschaulichung, eine Uhr wäre ausreichend. 

Formal lassen sich zeitgesteuerte Automaten wie folgt definieren [44]: Sei C 
eine Menge reellwertiger, nicht negativer Variablen, die Uhren darstellen. Sei X ein 
endliches Alphabet möglicher Eingaben. 


Definition 2.7: Eine Zeitbedingung ist eine konjunktive Formel atomarer Bedin- 
gungen der Form x o n oder (x — y) on mit x,y € C,o € {s,<,=,>,>}undneN. 


Die verwendeten Konstanten n der Bedingungen miissen ganzzahlig sein, auch 
wenn die Uhren reellwertig sind. Eine Erweiterung auf rationale Konstanten wäre 
einfach, da diese sich einfach durch Multiplikation in ganze Zahlen wandeln lassen. 
Sei B(C) die Menge an Zeitbedingungen. 
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Definition 2.8 (Bengtson [44]): Ein zeitgesteuerter Automat ist ein Tupel (S, so, E, J) 
mit: 


e einer endlichen Menge an Zuständen S, 

e einem Anfangszustand so, 

e der Kantenmenge E C S x B(C) x = x 2© x S. B(C) modelliert die konjunktive 
Bedingung, die gelten muss, und £ modelliert den Eingang, der für die Aktivie- 
rung eines Übergangs notwendig ist. 2© stellt die Menge an Uhrvariablen dar, die 
zurückgesetzt werden, wenn die Transition aktiv wird. 

e 1:8 — B(C) ist die Menge der Invarianten für jeden einzelnen Zustand. B(C) 
stellt die für einen bestimmten Zustand S zutreffende Invariante dar. Diese Inva- 
riante wird durch eine konjunktive Formel beschrieben. 


Diese erste Definition wird meist erweitert, um parallel arbeitende zeitgesteuerte 
Automaten beschreiben zu können. Zeitgesteuerte Automaten mit einer großen An- 
zahl von Uhren sind meist schwer zu verstehen. Weitere Details über zeitgesteuerte 
Automaten finden sich z.B. in Veröffentlichungen von Dill etal. [133] und Bengtsson 
et al. [44]. 

Die Simulation und Verifikation von zeitbehafteten Automaten ist mit dem po- 
pulären Werkzeug UPPAAL möglich!!. UPPAAL unterstützt Nebenläufigkeit und 
Datenvariablen. 

Zeitgesteuerte Automaten erweitern klassische Automaten um Zeitinformation. 
Sie erfüllen damit aber viele unserer anderen Anforderungen an Spezifikationstech- 
niken nicht. Insbesondere verfügen sie in der hier beschriebenen Standardform weder 
über Hierarchie noch über Nebenläufigkeit. 


2.4.2 StateCharts: implizite Kommunikation über gemeinsamen 
Speicher 


Die hier vorgestellte StateCharts-Sprache ist ein bekanntes Beispiel einer automa- 
tenbasierten Sprache, die hierarchische Modelle und Nebenläufigkeit unterstützt. Sie 
beinhaltet zudem eingeschränkte Möglichkeiten zur Angabe von Zeitinformationen. 
StateCharts wurde 1987 von David Harel [204] vorgestellt und später detaillierter 
beschrieben [141]. Den Namen hat Harel angeblich so gewählt, weil es „die einzige 
unbenutzte Kombination von flow oder state mit diagram oder chart “ war. 


Modellierung von Hierarchie 


Die StateCharts-Sprache beschreibt erweiterte endliche Automaten, sie ist daher gut 
dazu geeignet, zustandsorientiertes Verhalten abzubilden. Die wichtigste Erweite- 


1 Die akademische Version ist unter http://www.uppaal.org und die kommerzielle Version ist unter 
http://www.uppaal.com erhältlich. 
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rung gegeniiber klassischen Automaten ist das Konzept der Hierarchie. Hierarchie 
wird mit Hilfe von Superzuständen (engl. superstates) eingeführt. 


Definition 2.9: Zustände, die andere Zustände enthalten, heißen Superzustände 


Definition 2.10: Zustände, die in anderen Zuständen enthalten sind, heißen Unter- 
zustände (engl. substates) der Superzustände. 


Beispiel 2.9: Abb. 2.12 zeigt ein StateCharts-Beispiel. Es ist eine hierarchische Ver- 
sion von Abb. 2.10. Der Superzustand S beinhaltet die Unterzustände A, B, C, D 


Abb. 2.12 Hierarchisches S 
Zustandsdiagramm 


und E. Angenommen, der Automat befindet sich in Zustand Z (wir bezeichnen Z in 
diesem Fall auch als aktiven Zustand). Wenn dann die Eingabe m am Automaten 
erfolgt, ist A der nächste Zustand. Wenn sich der Automat in Zustand S befindet und 
es folgt die Eingabe k, so ist Z der nächste Zustand — unabhängig davon, in welchem 
der Unterzustände A, B, C, D oder E sich der Automat tatsächlich befindet. In diesem 
Beispiel sind alle in S enthaltenen Zustände nicht-hierarchische Zustände. V 


Im Allgemeinen könnten die Unterzustände von S auch selbst wieder Superzustände 
sein, die weitere Unterzustände enthalten. Immer, wenn ein Unterzustand eines 
Superzustands aktiv ist, ist auch der zugehörige Superzustand aktiv. 


Definition 2.11: Jeder Zustand, der nicht aus anderen Zuständen besteht, heißt Ba- 
siszustand. 


Der endliche Automat in Abb. 2.12 kann sich zu einem bestimmten Zeitpunkt nur 
in genau einem der Unterzustände des Superzustands 5 befinden. Solche Superzu- 
stände heißen ODER-Superzustände!?. 


Definition 2.12: Superzustände S heißen ODER-Superzustände, wenn das System, 
das S enthält, sich in genau einem Unterzustand von S befindet, solange es sich in $ 
befindet. 


In Abb. 2.12 könnte die Eingabe k einer Ausnahme entsprechen, wegen der 
Zustand S verlassen werden muss. Das Beispiel zeigt bereits, wie solche Ausnah- 
mebehandlungen durch Verwendung von Hierarchie kompakt dargestellt werden 
können. 


12 Gemeint ist hier immer ein sich gegenseitig ausschließendes ODER. 
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StateCharts erlaubt es, Systeme hierarchisch zu beschreiben, indem eine Be- 
schreibung des Systems Untersysteme enthält, die wiederum Beschreibungen von 
Unterzuständen enthalten können und so weiter. Das hierarchische Gesamtsystem 
kann somit in Form eines Baumes dargestellt werden. Die Wurzel dieses Baumes 
entspricht dem gesamten System und die inneren Knoten entsprechen hierarchischen 
Beschreibungen (die im Falle von StateCharts Superzustände heißen). Die Blätter 
der Hierarchie sind nicht-hierarchische Beschreibungen (die im Falle von StateCharts 
Basiszustände heißen). 

Bisher haben wir explizite, direkte Kanten verwendet, die zu Basiszuständen füh- 
ren, um den neuen Zustand zu bestimmen. Der Nachteil dieser Art der Modellierung 
liegt darin, dass man die internen Strukturen der Superzustände nicht vor der Umge- 
bung verstecken kann. In einem echten hierarchischen Modell sollte es möglich sein, 
die interne Struktur zu verstecken, sodass diese später beschrieben oder sogar geän- 
dert werden kann, ohne eine Auswirkung auf die Umgebung zu haben. Dies wird 
durch zusätzliche Mechanismen ermöglicht, die den neuen Zustand bestimmen. 

Der erste zusätzliche Mechanismus ist der Standardzustand (engl. default state). 
Er kann in Superzuständen verwendet werden, um anzuzeigen, welche der Unterzu- 
stände betreten werden, wenn der Superzustand betreten wird. In den Diagrammen 
wird der Standardzustand mit Hilfe einer Kante bezeichnet, die von einem kleinen 
ausgefüllten Kreis zum jeweiligen Zustand geht. 


Beispiel 2.10: Abb. 2.13 zeigt ein Zustandsdiagramm, das den Standardzustands- 
Mechanismus verwendet. Es ist äquivalent zum Diagramm in Abb. 2.12. Der kleine 
ausgefüllte Kreis stellt dabei selber keinen Zustand dar. 


Abb. 2.13 Zustandsdiagrammmit Standardzustand Vv 


Ein weiterer Mechanismus, um den nächsten Zustand anzugeben, ist der soge- 
nannte History-Zustand. Mit Hilfe dieses Konstrukts ist es möglich, in den letz- 
ten Unterzustand zurückzukehren, der aktiv war, bevor der Superzustand verlassen 
wurde. Der History-Mechanismus wird durch den Buchstaben H in einem Kreis 
dargestellt. Um den aktiven Zustand für den ersten Wechsel in einen Superzustand 
zu kennzeichnen, wird der History-Mechanismus oft mit einem Standardzustand 
kombiniert. 
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Beispiel 2.11: Eine Kombination von History- und Standardzustand wird in Abb. 
2.14 gezeigt. Das Verhalten des endlichen Automaten hat sich nun verändert: Sei 
der Automat zunächst im Zustand Z und es ereigne sich die Eingabe m. Dann ist 


Abb. 2.14 Zustandsdiagramm N 


mit History-Mechanismus und 
Standardzustand ; ; 
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A der nächste Zustand, wenn der Superzustand S zum ersten Mal betreten wird. 
Ansonsten wird der zuletzt aktive Unterzustand betreten. Dieser Mechanismus hat 
viele Anwendungen. Wenn z.B. die Eingabe k eine Ausnahme darstellt, könnte die 
Eingabe m verwendet werden, um in den Zustand vor der Ausnahme zurückzukehren. 
Die Zustände A, B, C, D und E könnten den Zustand Z auch wie eine Prozedur 
aufrufen. Nachdem diese ,,Prozedur” Z abgearbeitet ist, kehrt der Automat zum 
aufrufenden Zustand zurück. Auf diese Weise fügen wir StateCharts ein Element 
üblicher Programmiersprachen hinzu. 

Der Automat aus Abb. 2.14 kann auch wie in Abb. 2.15 dargestellt werden. In 
diesem Fall wurden die Darstellungen für den Standardzustand und den History- 
Mechanismus kombiniert. 


if, “ONOR 
~ 


Abb. 2.15 Kombination der Symbole für History- und Standardzustand Vv 


Eine Spezifikationstechnik muss auch in der Lage sein, Nebenläufigkeit und 
Parallelität darzustellen. Zu diesem Zweck gibt es in StateCharts eine zweite Art von 
Superzuständen, die sogenannten UND-Superzustände. 


Definition 2.13: Superzustände S heißen UND-Superzustände, wenn das System, 
das S enthält, sich in allen Unterzuständen von S gleichzeitig befindet, solange es 
sich in S befindet. 
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Beispiel 2.12: Das Diagramm fiir einen Anrufbeantworter in Abb. 2.16 enthält einen 
UND-Superzustand. Ein Anrufbeantworter muss normalerweise zwei Aufgaben par- 


Anrufbeantworter 


ein 


einstein 


Abb. 2.16 Anrufbeantworter 


allel ausführen: er wartet auf ankommende Anrufe und überprüft gleichzeitig, ob 
der Benutzer etwas auf den Eingabetasten eingegeben hat. In Abb. 2.16 heißen die 
entsprechenden Zustände Lwait und Kwait. Ankommende Anrufe werden im Zu- 
stand Lproc abgearbeitet, während Reaktionen auf die Eingabetasten im Zustand 
Kproc erzeugt werden. Der Zustand Lproc wird verlassen, wenn der Anrufer auflegt. 
Legt der Angerufene auf, so wird nicht automatisch zum Zustand Lwait zurückge- 
kehrt. Bei unerwünschten Anrufen kann er also bei diesem Modell nicht einfach den 
Anfangszustand wiederherstellen. 

Der Ein/Ausschalter wird fürs Erste so modelliert, dass die von ihm erzeugten 
Ereignisse (Einschalten und Ausschalten) separat dekodiert werden und somit nicht 
in den Zustand Kproc gewechselt wird. Wird der Anrufbeantworter ausgeschaltet, so 
werden die beiden im ein-Zustand enthaltenen Zustände verlassen. Sie werden erst 
wieder betreten, wenn der Anrufbeantworter wieder eingeschaltet wird. Zu diesem 
Zeitpunkt werden dann die Standardzustände Lwait und Kwait betreten. Solange die 
Maschine eingeschaltet ist, befindet sie sich immer in den beiden Unterzuständen 
des Zustands ein. V 


Für UND-Superzustände können die Unterzustände, die als Reaktion auf ein Er- 
eignis betreten werden, unabhängig voneinander beschrieben werden. Jede beliebige 
Kombination von History-und Standardzuständen sowie expliziten Transitionen ist 
möglich. Für das Verständnis von StateCharts ist es wichtig zu begreifen, dass immer 
alle Unterzustände betreten werden, auch wenn es nur eine einzige explizite Tran- 
sition zu einem der Unterzustände gibt. Analog dazu gilt, dass eine Transition aus 
einem UND-Superzustand heraus immer dazu führt, dass alle seine Unterzustände 
verlassen werden. 
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Beispiel 2.13: Als Beispiel modifizieren wir unseren Anrufbeantworter so, dass der 
Ein/Ausschalter wie alle anderen Bedientasten im Zustand Kproc dekodiert und 
behandelt wird (siehe Abb. 2.17). Wenn der Anrufbeantworter ausgeschaltet wird, 


Anrufbeantworter 


ein 
Anrufverarbeitung 


Tastenverarbeitung 


Klingeln 


Auflegen 
(Anrufer) 


Einschalten 
Ausschalten 


Abb. 2.17 Anrufbeantworter mit veränderter Ein/Ausschalter-Modellierung 


findet eine Transition in den aus-Zustand statt. Dieser Ubergang fiihrt dazu, dass 
auch der Zustand, der auf ankommende Anrufe wartet, verlassen wird. Das Wie- 
dereinschalten der Maschine fiihrt dazu, dass eben dieser Zustand auch wieder mit 
betreten wird. V 


UND-Superzustände sind der wichtigste Mechanismus, um Nebenläufigkeit in 
StateCharts zu beschreiben. Jeder Unterzustand kann als eigener Automat angese- 
hen werden. Diese Automaten kommunizieren miteinander und werden damit zu 
kommunizierenden endlichen Automaten (engl. Communicating Finite State Ma- 
chines (CFSMs)). Dieser Begriff wurde als Titel dieses Abschnitts gewählt. 

Zusammenfassend können wir festhalten: Zustände in StateCharts sind entwe- 
der UND-Superzustände, ODER-Superzustände oder Basiszustände. 


Zeitgeber 


Da es notwendig ist, in eingebetteten Systemen Zeitbedingungen zu modellieren, 
bietet StateCharts die sogenannten Timer oder Zeitgeber an. Zeitgeber werden durch 
das gezackte Symbol in Abb. 2.18 dargestellt. 
Wenn das System für die im Timer angegebene Zeitdauer im Timer-Zustand war, 
wird ein Timeout ausgelöst und das System verlässt diesen Zustand. Zeitgeber können 
auch hierarchisch verwendet werden. 

Ein Zeitgeber könnte beispielsweise in einer tieferen Hierarchiestufe des Anrufbe- 
antworters verwendet werden, um das Verhalten des Zustands Lproc zu beschreiben. 
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Abb. 2.18 Zeitgeber AM i 


in StateCharts 
a 20 ms 


timeout 


Abb. 2.19 zeigt eine mögliche Beschreibung für diesen Zustand. Die Spezifikati- 
on ist damit leicht anders als die in Abb. 2.11. Da das Auflegen des Anrufers in 


Abb. 2.19 Behandlung von ein- Lproc 
gehenden Anrufen in Lproc 


Abb. 2.16 in Form einer Ausnahmebehandlung realisiert ist, wird der Zustand Lproc 
immer erst dann verlassen, wenn der Anrufer auflegt. Wenn allerdings der Ange- 
rufene auflegt, hat der Entwurf des Zustands Lproc einen Schönheitsfehler: wenn 
der Angerufene zuerst auflegt, ist das Telefon solange tot (und still), bis der Anrufer 
ebenfalls aufgelegt hat. 

StateCharts beinhalten noch weitere Sprachelemente, die beispielsweise im Buch 
von Harel [204] zu finden sind. Zusammen mit Drusinsky gibt Harel [141] in einem 
Artikel eine genauere Beschreibung der Semantik von StateMate, einer StateCharts- 
Implementierung. 


Kantenbeschriftungen und die StateMate-Semantik 


Die Ausgabe der erweiterten Automatenmodelle wurde bislang noch nicht betrach- 
tet. Solche Ausgaben können mit Hilfe von Kantenbeschriftungen realisiert werden. 
Die allgemeine Form einer Kantenbeschriftung ist „Ereignis [Bedingung] / Reakti- 
on“. Alle drei Bestandteile der Beschriftung sind optional. Die Reaktion beschreibt 
die Reaktion des Automaten auf den Zustandsübergang. Mögliche Reaktionen bein- 
halten das Erzeugen von Ereignissen oder die Zuweisung von Variablenwerten. 
Bedingung und Ereignis beschreiben zusammen die Eingaben an den Automaten. 
Die Bedingung beschreibt das Überprüfen von Werten von Variablen oder des Zu- 
stands des Gesamtsystems. Der Ereignisteil symbolisiert, auf welches Ereignis zu 
prüfen ist. Solche Ereignisse können entweder intern oder extern erzeugt werden. 
Interne Ereignisse werden als Ergebnis von Zustandsübergängen erzeugt und in der 
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Reaktion des Übergangs beschrieben. Externe Ereignisse werden üblicherweise in 
der Systemumgebung beschrieben. Beispiele: 


e Einschalten / Ein:=1 (Test auf ein Ereignis und Wertzuweisung an eine Variable), 

« [Ein=1] (Überprüfung eines Variablenwerts), 

e Ausschalten [not in Lproc] / Ein:=0 (Ereignistest, Überprüfung eines Zustands, 
Variablenzuweisung. Die Zuweisung wird nur durchgeführt, wenn das Ereignis 
stattgefunden hat und die Bedingung erfüllt ist). 


Die Semantik der Kantenbeschriftungen kann nur im Zusammenhang mit der 
generellen Semantik von StateCharts erklärt werden. Die StateMate-Implementie- 
rung von StateCharts [141] geht von einer schrittweisen Ausführung von StateCharts- 
Beschreibungen aus, wie in Abb. 2.20 gezeigt. Schritte werden jedes Mal ausgeführt, 


Status Schritt Status Schritt Status Schritt Status 
œ >O- 


3 Phasen 3 Phasen 3 Phasen 


Abb. 2.20 Schritte während der Ausführung eines StateMate-Modells 


wenn ein Ereignis eintritt oder sich ein Variablenwert geandert hat. Unter dem Status 
verstehen wir die Menge aller Variablenwerte, die Menge der erzeugten Ereignisse, 
die Menge der aktuellen Zustände und die aktuelle Zeit. 

Das Konzept der Schritte erlaubt es, die Semantik von Ereignissen genauer zu de- 
finieren. Die Sichtbarkeit von Ereignissen ist auf denjenigen Schritt beschränkt, 
der auf den Schritt folgt, in dem das Ereignis erzeugt wurde. Somit verhalten 
sich Ereignisse wie Bitwerte, die bei einer Taktflanke in Registern abgelegt werden 
und einen Einfluss auf die bei der nächsten Taktflanke gespeicherten Werte haben. 
Ereignisse „leben“ nur bis zum nächsten Schritt bzw. bis zur nächsten Taktflanke. 

Im Gegensatz dazu behalten Variablen ihren Wert, bis ihnen ein neuer Wert 
zugewiesen wird. Nach der StateMate-Semantik sind neue Werte von Variablen in 
allen Teilen des Modells sichtbar, und zwar ab demjenigen Schritt, der auf den 
Schritt folgt, in dem die Wertzuweisung erfolgt ist. Das bedeutet, dass die Semantik 
von StateMate neue Variablenwerte zwischen zwei Schritten überall im Modell 
propagiert und sichtbar macht. Jeder Schritt besteht aus drei Phasen: 


1. In der ersten Phase wird der Einfluss von externen Bedingungen und Ereignissen 
ausgewertet. Das beinhaltet auch die Auswertung von Funktionen, die von exter- 
nen Ereignissen abhängen. In dieser Phase gibt es keine Zustandsübergänge. In 
unseren einfachen Beispielen wird diese Phase nicht unbedingt benötigt. 

2. Die nächste Phase besteht darin, die Menge der Zustandsübergänge zu bestim- 
men, die im aktuellen Schritt ausgeführt werden sollen. Variablenzuweisungen 
werden ausgewertet, aber die neuen Werte werden nur temporären Hilfsvariablen 
zugewiesen. 
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3. Inder dritten Phase finden die Zustandsübergänge statt und die Variablen erhalten 
ihre neuen Werte. 


Die Aufteilung in die Phasen 2 und 3 ist besonders wichtig, um ein determi- 
nistisches und reproduzierbares Verhalten von StateCharts-Modellen zu erreichen. 


Beispiel 2.14: Wir betrachten das StateCharts-Modell in Abb. 2.21. 


swap 
| 
| 
| 
| 
| 
| 
oS | = 
e/a:=b e/b:=a 
| 


Abb. 2.21 Gegenseitige, abhängige Wertzuweisung 


In der zweiten Phase werden bei Eintreten des Ereignisses e die neuen Werte für 
a und b zunächst in temporären Variablen, z.B. a’ und b’, zwischengespeichert. In 
der letzten Phase werden diese Zwischenwerte dann in die eigentlichen Variablen 
kopiert: 


phase 2: a’:=b; b’:=a; 
phase 3: a:=a’; b:=b’; 


Dadurch werden die Werte der beiden Variablen jedes Mal vertauscht, wenn 
das Ereignis e eintritt. Dieses Verhalten entspricht zwei über Kreuz verbundenen 


Abb. 2.22 Über Kreuz verbundene Register Takt Tr] 


Registern (eines für jede Variable), die an der gleichen Taktleitung angeschlossen 
sind (siehe Abb. 2.22) und modelliert das Verhalten eines getakteten Schaltwerks, 
das diese zwei Register enthält!?. V 


13 Wir verwenden in diesem Buch durchgehend in allen Schaltungen die IEEE-Standardsymbole 
[239] für Gatter und Register. Die Symbole in Abb. 2.22 stellen getaktete Register vom D-Typ dar. 
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Ohne die Aufteilung in zwei Phasen wiirde beiden Variablen derselbe Wert zu- 
gewiesen. Das Ergebnis würde von der Reihenfolge der Ausführung der Wertzu- 
weisungen abhängen. Diese Aufteilung in (mindestens) zwei Phasen ist typisch für 
Sprachen, die das Verhalten von synchroner Hardware nachbilden. Eine ähnliche 
Aufteilung findet sich auch in VHDL (siehe Seite 118). Durch diese Trennung hän- 
gen die Ergebnisse nicht von der Reihenfolge ab, in der Teile des Modells in der 
Simulation ausgeführt werden. Dies ist eine extrem wichtige Eigenschaft. Ohne die- 
se würden verschiedene Simulationsläufe unterschiedliche Ergebnisse erzeugen, die 
alle als korrekt angesehen werden können. Dies wäre eine sehr verwirrende Eigen- 
schaft des Modells und entspricht nicht dem, was wir von einer Simulation einer 
realen Schaltung mit festem Verhalten erwarten. 


e Kahn [279] nennt diese Eigenschaft „determinate”. 
e In anderen Veröffentlichungen wird die Eigenschaft deterministisch genannt. 
Dieser Begriff ist aber mit mehreren Bedeutungen überladen: 


— Der Begriff bezeichnet nichtdeterministische endliche Automaten, die sich 
zugleich in mehreren Zuständen befinden können [222]. 

— Sprachen können nichtdeterministische Operatoren besitzen. Diese Operatoren 
besitzen mehrere zulässige Implementierungen. 

— Viele Autoren bezeichnen ein System als nichtdeterministisch, wenn sein Ver- 
halten von einer Eingabe zur Laufzeit abhängt. 

— Inder Bedeutung von Kahns Begriff „determinate”. 


In diesem Buch verwenden wir den Begriff „deterministisch” im Sinne von Kahns 
Begriff ,, determinate’. StateMate-Modelle können nur deterministisch sein, wenn 
es keine anderen Gründe fiir undefiniertes Verhalten gibt. So könnten z.B. Konflikte 
zwischen verschiedenen Transitionen erlaubt sein, wie in Abb. 2.23 gezeigt. Wenn in 


Abb. 2.23 Links: Konflikt 


zwischen Schachtelungstiefen; A 
rechts: Konflikt auf 


derselben Tiefe 
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Abb. 2.23 (links) das Ereignis A eintritt, wahrend sich das System im linken Zustand 
befindet, müssen wir bestimmen, welche Transition ausgeführt werden soll. Wenn 
diese Konflikte auf beliebige Weise aufgelöst würden, wäre das Verhalten nichtdeter- 
ministisch. Meist werden deshalb Prioritäten definiert, damit diese Art von Konflikt 
aufgelöst werden kann. In Abb. 2.23 (rechts) liegt ein Konflikt beispielsweise für 
den Fall x = 15 vor. Solche Konflikte sind nur schwer zu erkennen. Um determinis- 
tisches Verhalten zu erreichen, dürfen keine Konflikte vorhanden sein, die in einer 
beliebigen Weise aufgelöst werden. 

Es mag aber auch Fälle geben, in denen wir nichtdeterministisches Verhalten 
beschreiben wollen, z.B. wenn von zwei verschiedenen Eingängen gelesen werden 
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kann. In einem solchen Fall möchten wir explizit angeben können, dass diese Ent- 
scheidung zur Laufzeit stattfinden wird (vergleiche die select-Anweisung von Ada 
auf Seite 124). 

Andere Implementierungen hierarchischer StateCharts zeigen meist nicht die- 
ses von StateMate realisierte deterministische Verhalten. Diese Implementierungen 
entsprechen einer Softwaresicht hierarchischer StateCharts. In solchen Implemen- 
tierungen werden Wahlmöglichkeiten meist nicht explizit beschrieben. 


Bewertung und Erweiterungen 


Implizit geht StateCharts gemäß StateMate-Semantik also von einem Broadcast- 
Mechanismus zum Aktualisieren von Variablenwerten aus. Dadurch lassen sich 
StateCharts oder StateMate-Modelle leicht auf shared memory-Systemen imple- 
mentieren, eignen sich aber weniger für verteilte und nachrichtenbasierte Systeme. 
Somit setzen Sprachen wie StateCharts implizit die shared memory-Semantik vor- 
aus, auch wenn dies nicht explizit festgelegt wird. Bei verteilten Systemen ist es sehr 
schwierig, alle Variablenwerte zwischen zwei Schritten zu aktualisieren. Aufgrund 
dieses Broadcast-Mechanismus sind StateCharts mit der beschriebenen Semantik 
nicht geeignet, um verteilte Systeme zu beschreiben. Das Hauptanwendungsgebiet 
von StateCharts sind daher lokale Systeme, die hauptsächlich Steuerungsaufgaben 
durchführen. Die Möglichkeit, Hierarchieebenen beliebig zu verschachteln und mit 
frei wählbaren UND- und ODER-Superzuständen zu versehen, ist der Hauptvor- 
teil von StateCharts. Ein weiterer Vorteil ist die ausreichend präzise Definition der 
Semantik von StateCharts [141] gemäß StateMate-Implementierung. Außerdem ist 
eine Vielzahl von kommerziellen Programmen erhältlich, die StateCharts verwen- 
den. StateMate [230] und StateFlow [383] sind Beispiele für solche kommerziellen 
Anwendungen. Viele dieser Programme sind in der Lage, aus StateCharts-Modellen 
äquivalente Beschreibungen in C oder VHDL (siehe Seite 109) zu erzeugen. Aus 
VHDL kann mit Hilfe von Synthesewerkzeugen direkt Hardware erzeugt werden. 
Aus diesem Grund bieten Programme, die auf StateCharts basieren, einen vollstän- 
digen Entwurfspfad von der StateCharts-Beschreibung bis zur fertigen Hardware. 
Generierte C-Programme können übersetzt und ausgeführt werden, was auch Soft- 
warerealisierungen ermöglicht. 

Leider ist die Effizienz dieser automatisch erzeugten Realisierungen häufig ein 
Problem. So könnten in einer automatisch erzeugten Software etwa Unterzustände 
von UND-Superzuständen auf Unix-Prozesse abgebildet werden. Dieses Konzept ist 
für die Simulation von StateCharts geeignet, nicht jedoch für eine effiziente Realisie- 
rung auf kleinen, leistungsschwachen Prozessoren. Der Produktivitätsgewinn durch 
objektorientierte Programmierung kann mit StateCharts nicht ausgeschöpft werden, 
da Objektorientierung nicht unterstützt wird. Außerdem ist es durch den Broadcast- 
Mechanismus kaum für verteilte Anwendungen geeignet. StateCharts unterstützen 
keine Programmiersprachenkonstrukte, um komplexe Berechnungsvorschriften zu 
realisieren. Außerdem können sie keine Hardwarestrukturen oder nicht-funktionales 
Verhalten beschreiben. 
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Kommerzielle Implementierungen von StateCharts bieten tiblicherweise einige 
Mechanismen, um die Nachteile von StateCharts zu umgehen. So kann etwa C- 
Code verwendet werden, um Programmiersprachenkonstrukte zu unterstützen. In 
StateMate stellen die sogenannten Module Charts Hardwarestrukturen dar. 

In Bezug auf Zeitbedingungen ermöglichen StateCharts nur die Angabe von 
Timeouts. Es gibt keine weitere direkte Möglichkeit, andere Zeitbedingungen anzu- 
geben. 

UML beinhaltet eine Version von StateCharts und erlaubt damit die Modellierung 
endlicher Automaten. UML Version 1 nennt diese state diagrams, während sie ab 
UML 2.0 state machine diagrams genannt werden. Leider unterscheidet sich die 
Semantik der UML-Diagramme von StateMate, da UML die drei beschriebenen 
Simulationsphasen nicht vorgibt. 


2.4.3 Synchrone Sprachen 


Motivation 


Es ist schwierig, komplexe Systeme mit Hilfe endlicher Automaten zu beschrei- 
ben, da diese keine komplexen Berechnungen enthalten. Standard-Programmierspra- 
chen dagegen können komplexe Berechnungen beschreiben, garantieren dafür aber 
meist nicht die Ausführungsreihenfolge mehrerer Threads. In einer Multi-Threaded- 
Umgebung mit präemptivem (d.h. verdrängendem) Scheduling sind viele verschie- 
dene Ablaufreihenfolgen der einzelnen Berechnungen möglich. Es ist schwer, alle 
möglichen Abläufe in einem solchen nebenläufigen System zu verstehen. Einer der 
Hauptgründe dafür ist, dass im Allgemeinen mehrere verschiedene Ausführungsrei- 
henfolgen möglich sind, die Reihenfolge der Ausführung ist also nicht festgelegt. 
Allerdings kann diese Reihenfolge durchaus das Ergebnis beeinflussen. Das sich 
daraus ergebende nichtdeterministische Verhalten kann eine Reihe von Problemen 
zur Folge haben, wie z.B. das Problem, einen bestimmten Entwurf zu verifizieren. 
Bei verteilten Systemen mit unabhängigen Uhren ist deterministisches Verhalten nur 
schwer realisierbar. Bei nicht verteilten Systemen können wir aber versuchen, die 
Probleme einer unnötig nichtdeterministischen Semantik zu vermeiden. 

Synchrone Sprachen verbinden endliche Automaten und Programmiersprachen zu 
einem Modell. Sie können komplexe Berechnungen beschreiben, folgen aber dem zu 
Grunde liegenden Ausführungsmodell endlicher Automaten. Dabei beschreiben sie 
nebenläufig arbeitende Automaten. Deterministisches Verhalten wird durch die fol- 
gende wichtige Eigenschaft erreicht: „wenn Automaten parallel kombiniert werden, 
dann besteht eine Transition des zusammengesetzten Automaten aus der ‚gleichzei- 
tigen‘ Transition aller einzelnen Automaten” [198]. Das bedeutet, dass man nicht 
alle möglichen Abfolgen von Zustandsübergängen aller Automaten betrachten muss, 
wie dies bei unabhängigen Takten in den Unterautomaten der Fall wäre. Stattdes- 
sen kann man die Existenz eines einzigen globalen Taktes annehmen. Bei jedem 
Taktsignal werden alle Eingaben berücksichtigt, neue Ausgaben und Zustände wer- 
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den berechnet und die entsprechenden Zustandsübergänge ausgeführt. Dazu ist ein 
schneller Broadcast-Mechanismus notwendig, der alle Teile des Modells erreicht. 
Diese idealisierte Betrachtung von Gleichzeitigkeit hat den Vorteil, dass dadurch 
deterministisches Verhalten garantiert wird. Es stellt eine Einschränkung des all- 
gemeinen Modells kommunizierender Automaten dar, bei dem jeder Automat seinen 
eigenen Takt haben darf. Synchrone Sprachen stellen das Prinzip der Gleichzeitig- 
keit in synchroner Hardware dar und repräsentieren die Semantik von Sprachen für 
Industriesteuerungen wie IEC 60848 [232] und STEP 7 [488]. Ein Überblick über 
synchrone Sprachen ist bei Potop-Butucaru et al. [458] zu finden. 


Beispiele für synchrone Sprachen: Esterel, Lustre und SCADE 


Ein deterministisches Verhalten für alle Sprachkonstrukte zu garantieren, war eines 
der Hauptziele bei der Entwicklung der synchronen Sprachen Esterel [154, 61] , 
Lustre [200] und Quartz [480]. 

Esterel ist eine reaktive Sprache: wenn Esterel-Modelle mit einem Eingabeereig- 
nis aktiviert werden, reagieren sie mit der Erzeugung eines Ausgabeereignisses. 
Esterel ist eine synchrone Sprache: es wird angenommen, dass alle Reaktionen ohne 
Zeitverzögerung abgeschlossen werden, und dass es ausreichend ist, das Verhalten 
zu diskreten Zeitpunkten zu analysieren. Dieses idealisierte Modell vermeidet die 
Probleme von überlappenden Zeiträumen und von Ereignissen, die ankommen, wäh- 
rend die vorhergehende Reaktion noch nicht abgeschlossen war. Wie andere Sprachen 
auch, hat Esterel einen Parallelisierungsoperator, der als || geschrieben wird. Wie 
in StateCharts findet Kommunikation über einen Broadcast-Mechanismus statt. Im 
Gegensatz zu StateCharts findet die Kommunikation allerdings augenblicklich, ohne 
jede Verzögerung, statt. Das bedeutet, dass alle Signale, die zu einem bestimmten 
Zeitpunkt erzeugt werden, in genau diesem Zeitpunkt auch von allen anderen Teilen 
des Modells gesehen werden. Wenn diese anderen Teile sensitiv auf die erzeugten 
Signale reagieren, reagieren sie auch in genau diesem einen Zeitpunkt. Dabei kön- 
nen mehrere Runden von Auswertungen erforderlich sein, bis schließlich ein stabiler 
Zustand erreicht wird. Die dadurch maximal mögliche Antwortzeit wird beispiels- 
weise von Boldt et al. berechnet [56]. Diese Weiterleitung von Werten während ein 
und derselben makroskopischen Zeiteinheit entspricht der Erzeugung des nächsten 
Zustands für den gleichen Zeitpunkt in StateCharts, wobei der Broadcast hier au- 
genblicklich geschieht. Für weitere aktuelle Informationen zu Esterel verweisen wir 
auf die Web-Seite [154]. 

Esterel und Lustre verwenden eine unterschiedliche Syntax, um kommunizieren- 
de endliche Automaten zu beschreiben. Esterel sieht dabei wie eine imperative Pro- 
grammiersprache aus, wogegen Lustre eher an eine Datenflusssprache erinnert (siehe 
Seite 75 für eine Beschreibung von Datenflussmodellen). Eine grafische Version von 
Esterel ist mit SyncCharts verfügbar. Alle diese Implementierungen verwenden die 
Semantik der zu Grunde liegenden kommunizierenden endlichen Automaten. Die 
kommerziell verfügbare graphische Sprache SCADE [18] verbindet Elemente al- 
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ler drei Sprachen. Die SCADE Suite® wird fiir sicherheitskritische Komponenten 
eingesetzt, z.B. von Airbus. 

Aufgrund der drei Simulationsphasen kann auch StateMate als synchrone Sprache 
angesehen werden. StateMate ist deterministisch, wenn Konflikte aufgelöst werden. 
Laut Halbwachs ist „StateMate fast eine synchrone Sprache, die einzige Eigenschaft, 
die StateMate fehlt, ist der augenblickliche Broadcast-Mechanismus” [199]. 


2.4.4 Nachrichtenaustausch am Beispiel von SDL 


Spracheigenschaften 


Wegen der Kommunikation über gemeinsamen Speicher und aufgrund des Broad- 
cast-Mechanismus sind StateCharts für die Modellierung verteilter Systeme unge- 
eignet. Nachrichtenaustausch ist das für verteilte Systeme besser geeignete Kom- 
munikationsparadigma. Wir stellen daher nun eine zweite Sprache vor, die auch auf 
kommunizierenden endlichen Automaten basiert, aber asynchronen Nachrichtenaus- 
tausch nutzt. 

Wir benutzen die Sprache SDL (Specification and Description Language) als 
ein Beispiel. SDL wurde speziell für verteilte Anwendungen entwickelt. Die erste 
Entwicklung begann in den siebziger Jahren des letzten Jahrhunderts, die formale 
Semantik von SDL wurde in den späten achtziger Jahren definiert. Die Sprache ist 
von der ITU (International Telecommunication Union) standardisiert worden. Der 
erste Standard, „Z.100 Recommendation“ wurde 1980 veröffentlicht und u.a. in den 
Jahren 1992, 1999, 2011 und 2016 aktualisiert [483]. Die Aktualisierung von 1999 
ist als SDL-2000 bekannt. 

Viele Anwender bevorzugen graphische Spezifikationssprachen, während andere 
textuelle Spezifikationen vorziehen. SDL bietet beide Möglichkeiten. Die Basisele- 
mente von SDL sind sogenannte Prozesse. SDL-Prozesse stellen erweiterte endliche 
Automaten dar. Abb. 2.24 zeigt die Symbole, die in der graphischen Repräsentation 
von SDL verwendet werden. 


C _ >D Identifiziert Anfangszustand Zustand 
< Eingabe > Ausgabe 


Abb. 2.24 Symbole in der graphischen Darstellung von SDL 


Beispiel 2.15: Als Beispiel soll gezeigt werden, wie man das Zustandsdiagramm in 
Abb. 2.25 in SDL darstellen kann. Abb. 2.25 unterscheidet sich von Abb. 2.13 auf 
Seite 57 durch das Hinzufügen von Ausgabewerten, das Entfernen des Zustands Z 
und die veränderte Wirkung des Signals k. 
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Abb. 2.25 Ein endlicher 
Automat 


Abb. 2.26 zeigt die zugehörige graphische SDL-Darstellung. Offensichtlich ist die 
Darstellung äquivalent zum Zustandsdiagramm in Abb. 2.25. 


Ce > Process P1 


Ce EID 22 ED 
8 h i J f k 
DER sez ez 2 


Abb. 2.26 SDL-Darstellung von Abb. 2.25 Vv 


Als Erweiterung gegenüber klassischen endlichen Automaten können SDL- 
Prozesse Operationen auf Daten ausführen. Variablen können lokal für einen Prozess 
deklariert werden. Ihr Typ kann entweder vordefiniert werden oder er wird durch 
die SDL-Operation festgelegt. SDL unterstützt abstrakte Datentypen (ADTs). Die 
Syntax der Deklarationen und Operationen ist anderen Programmiersprachen sehr 
ähnlich. Abb. 2.27 zeigt Beispiele für Deklarationen, Zuweisungen und Entschei- 
dungen in SDL. 


Abb. 2.27 Deklarationen, DCL 


Zuweisungen und Ent- Counter Integer; 
scheidungen in SDL Date String; 


Counter := Counter + 3; 


Counter 


(1:10) (11:30) ELSE 
| V 
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SDL enthält auch Programmiersprachenelemente wie Prozeduren. Prozedurauf- 
rufe können auch graphisch dargestellt werden. Objektorientierte Elemente wurden 
1992 in die Sprache integriert und in SDL-2000 erweitert. 

Erweiterte endliche Automaten sind nur die Basiselemente von SDL-Beschrei- 
bungen. Im Allgemeinen besteht eine SDL-Beschreibung aus einer Menge von in- 
teragierenden SDL-Prozessen oder Automaten. Prozesse können Signale an ande- 
re Prozesse senden. Die Semantik der Interprozesskommunikation in SDL basiert 
auf First-In First-Out- (FIFO) Warteschlangen, die mit jedem Prozess verbunden 
sind. Pro Prozess gibt es dabei genau eine Warteschlange. Ein Signal, das an einen 
bestimmten Prozess geschickt wird, landet in dessen FIFO-Warteschlange (siehe 


Abb. 2.28). 
Prozess 3 


Prozess 2 


Abb. 2.28 SDL-Interprozesskommunikation 


Jeder SDL-Prozess entnimmt den nächsten verfügbaren Eintrag aus der FIFO- 
Warteschlange und prüft, ob er einem der Eingabewerte für den aktuellen Prozess 
und Zustand entspricht. Wenn das so ist, wird die zugehörige Transition ausgeführt 
und eine entsprechende Ausgabe erzeugt. Ein Eintrag in der FIFO-Warteschlange 
wird ignoriert, wenn er keinem der Eingabewerte entspricht (es sei denn, der so- 
genannte SAVE-Mechanismus wird verwendet). Die FIFO-Warteschlangen haben 
im Modell eine unendliche Kapazität. Das bedeutet, dass in der Semantik von 
SDL-Beschreibungen keine FIFO-Überläufe betrachtet werden. In echten Syste- 
men dagegen müssen die FIFO-Warteschlangen natürlich eine endliche Länge ha- 
ben. Dies ist eines der Probleme von SDL: um korrekte Realisierungen von einer 
SDL-Spezifikation abzuleiten, muss man garantierte sichere obere Schranken für die 
Länge der FIFO-Warteschlangen bestimmen. 

Prozess-Interaktionsdiagramme können verwendet werden, um zu visualisie- 
ren, welche Prozesse mit welchen anderen kommunizieren. Prozess-Interaktions- 
diagramme beinhalten Kanäle, die zum Senden und Empfangen von Signalen ver- 
wendet werden. Bei SDL beschreibt der Begriff „Signal“ Ein- und Ausgaben der 
modellierten Automaten. 


Beispiel 2.16: Abb. 2.29 zeigt ein Prozess-Interaktionsdiagramm B1 mit den Kanä- 
len Sw1 und Sw2 sowie den lokalen Signalen A und B. In Klammern stehen die 
Namen der Signale, die über den jeweiligen Kanal transportiert werden. 
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BLOCK B1 
process P1 process P2 


Signal A, B; 


Abb. 2.29 Prozess-Interaktionsdigramm Vv 


Es gibt drei Möglichkeiten, den Empfänger eines Signals anzugeben: 


1. Durch Prozess-Identifikatoren: durch die Angabe eines empfangenden SDL- 
Prozesses im graphischen Ausgabesymbol (siehe Abb. 2.30 (links)). 


Counter Counter 
TO OFFSPRING VIA Swi 


Abb. 2.30 Links: Empfänger über Prozess identifiziert; rechts: Empfänger über Kanal identifiziert 


Da Prozesse dynamisch generiert werden können, die Anzahl von Prozessen 
also nicht bereits zur Übersetzungszeit festgelegt werden muss, gibt der Wert 
OFFSPRING die Prozesse an, die von einem Prozess dynamisch generiert wurden. 

2. Explizit: durch die Angabe eines Kanalnamens (siehe Abb. 2.30 (rechts)). Sw1 
ist der Name eines Kanals. 

3. Implizit: Wenn es eine direkte Zuordnung von Signalen zu Kanälen gibt, wird 
bei Angabe eines Signals der jeweilige Kanal verwendet. Beispiel: in Abb. 2.29 
wird das Signal B implizit immer über Kanal Sw1 laufen. 


Ein SDL-Prozess kann nicht innerhalb eines anderen SDL-Prozesses definiert 
werden, Prozesse können also nicht verschachtelt werden. Sie können aber hierar- 
chisch in sogenannten Blöcken gruppiert werden. Blöcke auf der höchsten Hierar- 
chiestufe heißen Systeme. Systeme besitzen keine Kanäle an ihrem Rand, sofern 
die Umgebung auch als Block modelliert wird. Blöcke auf der untersten Hierarchie- 
stufe heißen Prozess-Interaktionsdiagramme. Prozess-Interaktionsdiagramme 
befinden sich eine Ebene oberhalb der Blätter einer hierarchischen Beschreibung. 


Beispiel 2.17: Block B1 kann in dazwischenliegenden Blöcken (etwa in B in 
Abb. 2.31) verwendet werden. 


Abb. 2.31 SDL-Block Block B 
C2 C4 
B1 B2 


| cs 
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Auf der obersten Ebene der Hierarchie haben wir das System (siehe Abb. 2.32). 


Abb. 2.32 SDL-System System S 


B A 


Abb. 2.33 zeigt die mit Blockdiagrammen der Abbildungen 2.29, 2.31 und 2.32 
modellierte Hierarchie. 


Abb. 2.33 SDL-Hierarchie 


Das Beispiel zeigt, dass Prozess-Interaktionsdiagramme sich eine Stufe oberhalb der 
Blätter der hierarchischen Beschreibung befinden. Systeme stellen die Wurzel der 
Hierarchie dar. V 


Einige Einschränkungen bei der Modellierung von Hierarchie wurden in SDL- 
2000 beseitigt. In SDL-2000 wurde die Ausdruckskraft von Blöcken und Prozessen 
angeglichen und durch ein allgemeines Agentenkonzept ersetzt. 

Zur Modellierung von Zeit enthält SDL Zeitgeber (engl. Timer). Zeitgeber 
können lokal für Prozesse deklariert werden. Sie können mit Hilfe von SET- 
Anweisungen gesetzt und zurückgesetzt werden. Diese Anweisungen besitzen zwei 
Parameter; eine absolute Zeit und einen Zeitgebernamen. Die absolute Zeit defi- 
niert, wann die Zeit abläuft. Die eingebaute Funktion now kann benutzt werden, 
um anzugeben, wann die SET-Anweisung auszuführen ist. Ein Signal wird in der 
Eingabeschlange gespeichert, wenn ein Zeitgeber abgelaufen ist. Der Name dieses 
Signals wird über den zweiten Parameter des Aufrufs von SET bereit gestellt. Das 
Signal wird typischerweise einen Zustandsübergang im Automaten auslösen. Aller- 
dings kann dieser Übergang durch andere Einträge in der Eingabe-Warteschlange, 
die zuerst verarbeitet werden müssen, verzögert werden. Daher ist dieses Zeitgeber- 
Konzept nicht für harte, sondern für weiche Zeitschranken geeignet, wie sie in der 
Telekommunikation vorkommen. Eine zweite eingebaute Funktion expirytime kann 
benutzt werden, um einige der Einschränkungen von now zu überwinden. 

Zeitgeber können mit der Funktion RESET zurückgesetzt werden. Damit wird das 
Zählen gestoppt. Das Signal wird aus der Eingabe-Warteschlange entfernt, wenn es 
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sich bereits dort befinden sollte. Zu Beginn der Ausfiihrung von SET wird implizit 
ein RESET ausgefiihrt. 


Beispiel 2.18: Abb. 2.34 zeigt die Verwendung eines Zeitgebers Z. Das Diagramm 
entspricht dem in Abb. 2.26, mit dem Unterschied, dass der Zeitgeber Z beim Uber- 
gang von Zustand D in Zustand E auf den Wert der aktuellen Zeit now + T gesetzt 
wird. Fiir die Transition von E nach A ist damit ein Timeout von T Zeiteinheiten 


as Process S Timer Z? 


A )C Bl € jC ) CE) 
y Y 
8 h i j < f Z 
y y 
w x y SET(now+T,Z) v 
B) E ) D E | RESET(Z) 
CEDEC 


Abb. 2.34 Benutzung des Zeitgebers Z 


definiert. Wenn diese Zeit verstrichen ist, bevor das Signal f eintrifft, findet ein 
Übergang in den Zustand A statt, bei dem kein Ausgabesignal v erzeugt wird. Eine 
streng periodische Verarbeitung mit einer Periode T ist auf diese Weise schwer zu 
erreichen, weil die anderen Einträge in der Eingabewarteschlange die Ausführung 
verzögern können. V 


Beispiel 2.19: SDL kann verwendet werden, um Protokollstapel in Rechnernetzwer- 
ken zu beschreiben. Abb. 2.35 zeigt drei Prozessoren, die durch einen Router ver- 
bunden werden. Die Kommunikation zwischen Prozessoren und dem Router basiert 


Abb. 2.35 Kleines System 
Rechnernetz, 
beschrieben Prozessor A| | Router Prozessor B | | Prozessor C 


in SDL E c a T pe | 


auf FIFO-Warteschlangen. Damit bietet SDL einen eingebauten Kommunikations- 
mechanismus, der realen Netzwerkprotokollen entspricht. 
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Sowohl die Prozessoren als auch der Router implementieren Protokolle mit ver- 
schiedenen Ebenen (siehe Abb. 2.36). Jede Ebene beschreibt die Kommunikation 
mit einer abstrakteren Schicht. Das Verhalten jeder Ebene wird meistens als end- 
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Schicht-1 
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Schicht-n 
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ER | 
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Abb. 2.36 Protokoll-Stapel in SDL 


licher Automat modelliert. Die genaue Beschreibung dieser Automaten hängt vom 
verwendeten Netzwerkprotokoll ab und kann sehr komplex werden. Typischerweise 
wird das Überprüfen und Behandeln von Fehlerbedingungen sowie das Sortieren 
und Weiterleiten von Informationspaketen realisiert. V 


Verfügbare Werkzeuge für SDL enthalten Schnittstellen zu UML (siehe Seite 133) 
und SCs (siehe Seite 47). Eine umfassende Liste verfügbarer Werkzeuge wird im 
SDL-Forum zur Verfügung gestellt [482]. Estelle [74] ist eine weitere Sprache, die 
zur Beschreibung von Kommunikationsprotokollen entworfen wurde. Ähnlich zu 
SDL stellt Estelle Kommunikation über Kanäle und FIFO-Puffer zur Verfügung. 
Versuche, Estelle und SDL zu vereinen, sind fehlgeschlagen. 


Bewertung von SDL 


SDL ist hervorragend zur Modellierung von verteilten Anwendungen geeignet und 
die Sprache ist weiterhin als Referenz für asynchronen Nachrichtenaustausch nütz- 
lich. SDL ist nicht in allen Situationen deterministisch, da die Reihenfolge, in der 
gleichzeitig ankommende Signale in die FIFO-Warteschlangen eingereiht werden, 
nicht spezifiziert ist. Alle möglichen Reihenfolgen sind damit möglich. Verlässliche 
Implementierungen erfordern das manchmal schwierige Bestimmen einer oberen 
Schranke für die Länge der FIFO-Warteschlangen. Hierzu gibt es umfangreiche 
Literatur. Die Modellierung von Zeitbedingungen ist ausreichend für weiche Zeit- 
schranken, aber nicht für harte Echtzeitbedingungen. Hierarchien werden nicht so 
wie in StateCharts unterstützt. Es gibt keine Beschreibung von nicht-funktionalen 
Eigenschaften und keine vollständige Unterstützung für Programmiersprachenkon- 
strukte, obwohl dies von den aktuellen Standards angestrebt wird. SDL wurde zum 
Beispiel für die Spezifikation von ISDN verwendet. Aktuell scheint es, dass das 
Interesse an SDL zu einem generellen Interesse an Systembeschreibungssprachen 
verallgemeinert wird, wie dies auch im SDL-Forum zum Ausdruck kommt [483]. 
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2.5 Datenfluss 


2.5.1 Uberblick 


Viele echte Anwendungen lassen sich sehr „natürlich” durch Datenflüsse beschrei- 
ben. Datenflussmodelle beschreiben den Weg, auf dem Daten von Komponente zu 
Komponente flieBen [146]. Jede Komponente transformiert die Daten dabei auf eine 
bestimmte Art. Eine mögliche Definition von Datenfluss ist die folgende: 


Definition 2.14 ([582]): Datenflussmodellierung ‚ist ein Vorgang, bei dem identifi- 
ziert, modelliert und dokumentiert wird, wie sich Daten in einem Informationssystem 
bewegen. Die Datenflussmodellierung betrachtet Prozesse (Aktivitäten, die Daten 
von einer Form in eine andere transformieren), Datenspeicher (Bereiche, in denen 
Daten aufbewahrt werden), externe Einheiten (die Daten an ein System senden oder 
Daten von diesem empfangen) und Datenflüsse (Wege, auf denen Daten fließen 
können)”. 


Ein Datenflussprogramm wird als gerichteter Graph angegeben, bei dem die 
Knoten, auch Aktoren genannt, Berechnungen und die Kanten Kommunikations- 
kanäle darstellen. Jeder Aktor führt funktionale Berechnungen aus, also Berechnun- 
gen, die alleine auf den Eingabewerten durchgeführt werden. Jeder Prozess in einem 
Datenflussgraphen ist in eine Folge von atomaren „Ausführungen” (engl. firings) 
aufgeteilt. Jede Aktivierung erzeugt und verbraucht Marken (engl. tokens). Von- 
Neumann-Programme geben eine totale Ordnung für die Ausführung von Befehlen 
vor. Datenflussprogramme vermeiden eine unnötige Vorgabe einer solchen totalen 
Ordnung. 


Beispiel 2.20: Abb. 2.37 zeigt als Beispiel den Datenfluss in einem Video-on- 
demand-System [299]. Kunden betreten das System über die Netzwerkschnittstelle. 
Ihr Zugriffswunsch wird der Warteschlange der Kunden hinzugefügt. 


Kundenliste }<— Zugriffskontrolle Warteschlange 
Į J Zuschauerbefehle 

Scheduler 3 

i © 

Į j) 38 z 

N =o 5 

Dateisystem 32 D 

T 5 

Zo N 


V N Zuschauer 
. . A _ a pe 
Speicher- Speicher- Video Netzwerk Videodaten 
subsystem steuerung daten schnittstelle = 


Abb. 2.37 Video on demand-System (blau: Speicher, gelb: Verarbeitung, griin: E/A) 
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Nach dem Passieren der Zugriffskontrolle werden die Videowiinsche fiir den 
Zugriff auf das Dateisystem eingeplant. In Kooperation mit der Speichersteuerung 
stellt das Dateisystem die Videos dem Kunden zur Verfiigung. V 


Für allgemeine Datenflussmodelle lassen sich geforderte Eigenschaften eines 
Systems nur schwer beweisen. Daher kommen meist eingeschränkte Modelle zum 
Einsatz. 

Ein spezieller Typ von Datenfluss wird benutzt, um in Rechnerarchitekturen 
dynamisches Scheduling von Befehlen zu realisieren. Dies bedeutet, dass die Rei- 
henfolge der Ausführung von Maschinenbefehlen nicht unbedingt ihrer Anordnung 
im Speicher entspricht, sondern dass diese Reihenfolge unter Beachtung von Daten- 
abhängigkeiten geändert werden kann. Man spricht deshalb auch von out-of-order 
scheduling. Es gibt zwei sehr bekannte Algorithmen für diese Form des dynamischen 
Schedulings: scoreboarding und den Tomasulo-Algorithmus [544]. Beide Algorith- 
men werden in Büchern zur Rechnerarchitektur im Detail vorgestellt (siehe z.B. 
Hennessy et al. [212]). Aus diesem Grund werden sie in diesem Buch nicht behan- 
delt. Es gibt allerdings Varianten dieser Algorithmen, die auf Task-Ebene angewandt 
werden (siehe z.B. Wang et al. [561]). 


2.5.2 Kahn-Prozessnetzwerke 


Kahn-Prozessnetzwerke (KPN) [279] sind ein Spezialfall solcher Datenflussmodel- 
le. KPNs bestehen aus Knoten und Kanten. Knoten entsprechen von einer Task 
bzw. einem Prozess ausgeführten Berechnungen. Wie alle Datenflussgraphen stellen 
auch KPN-Graphen nur die durchzuführenden Berechnungen und deren Abhän- 
gigkeiten voneinander dar, nicht aber die Reihenfolge, in der die Berechnungen 
durchgeführt werden müssen (im Gegensatz zu Spezifikationen in von-Neumann- 
Sprachen wie C). Die Kanten stellen Kommunikationskanäle mit potenziell unend- 
lich großen FIFOs dar. Auch wenn die Berechnungs- und Kommunikationszeiten 
variieren können, ist doch sichergestellt, dass Kommunikation innerhalb endlicher 
Zeit stattfindet. Schreibvorgänge in KPNs sind nicht-blockierend, da angenommen 
wird, dass die FIFOs eine entsprechende Größe aufweisen. Leseoperationen müs- 
sen einen bestimmten Kanal angeben, von dem gelesen werden soll. Dabei kann 
ein Knoten vor dem Leseversuch nicht überprüfen, ob Daten zur Verfügung stehen. 
Auch kann ein KPN-Prozess nicht auf Daten von mehr als einem Port gleichzei- 
tig warten. Leseoperationen werden blockiert, wenn ein KPN-Prozess versucht, aus 
einer leeren FIFO-Warteschlange zu lesen. Nur ein einziger KPN-Prozess darf aus 
einer bestimmten Warteschlange lesen, ebenso darf nur ein einziger Prozess in eine 
bestimmte Warteschlange schreiben. Wenn ein Prozess seine Ausgabedaten also an 
mehrere Nachfolger senden will, müssen die Daten innerhalb des Prozesses dupli- 
ziert werden. Es gibt keine anderen Methoden für die Kommunikation zwischen 
KPN-Prozessen. 
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Im folgenden Beispiel inkrementieren bzw. dekrementieren die Prozesse T1 und 
2 den jeweils vom Kommunikationspartner erhaltenen Wert: 


process tI(in int u, out int v){ 
int i; 
i = ð; 
for (;;) { 
send(i,v); /x sende i Uber Kanal v */ 
i = wait(u); /x lese i von Kanal u */ 
i = i-1; 
} 
} 
process T2(in int v, out int u){ 
int i; 
for (;;) { 
i = wait(v); 
i = itl; 
send(i,u); 
} 
} 


Eine graphische Darstellung dieses KPNs ist in Abb. 2.38 zu sehen. 


Abb. 2.38 Graphische Darstellung V 
eines KPNs FIFO 
u 
FIFO 


In diesem Beispiel werden die FIFOs nicht wirklich benötigt, da es hier nicht 
vorkommen kann, dass sich Nachrichten in den Kanälen anstauen. Dieses und weitere 
Beispiele lassen sich mit der Software levi simulieren [496]. 

Die Beschränkungen für Lese- und Schreibvorgänge ergeben eine sehr schöne 
Eigenschaft von KPNs: die Reihenfolge, in der ein Knoten Daten empfängt, wird 
fest durch die Folge von Leseoperationen vorgegeben und hängt damit nicht von 
der Reihenfolge ab, in der die Daten über die Kanäle übertragen werden. Damit 
ist die Abfolge von Operationen nicht von der Geschwindigkeit der Knoten abhän- 
gig, welche die Daten produzieren. Für eine gegebene Menge an Eingabedaten 
erzeugen KPNs stets dasselbe Ergebnis, unabhängig von der Geschwindigkeit 
der Knoten. Diese Eigenschaft ist z.B. für Simulationen wichtig. Das Ergebnis der 
Simulation ist unabhängig davon, wie schnell das KPN simuliert wird. Auch der Ein- 
satz von Hardwarebeschleunigern in einigen Knoten und einer verteilten Ausführung 
führen nicht zu unterschiedlichen Ergebnissen im Vergleich zu einem zentralen Si- 
mulationsansatz. Diese Eigenschaft wird „deterministisch”!* genannt. Die von SDL 


14 Wieder im Sinne von ,, determinate”. 
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bekannten FIFO-Konflikte existieren hier nicht. Diese schöne Eigenschaft hat zur 
Folge, dass KPNs häufig als interne Repräsentation innerhalb eines Entwurfsflusses 
verwendet werden. 

KPNs können durch einen merge-Operator erweitert werden (ähnlich der select- 
Anweisung in Ada, siehe Seite 124). Dieser erlaubt es, Leseaufträge für mehrere 
Kanäle in eine Warteschlange einzureihen und darauf zu warten, dass einer der 
Kanäle Daten erzeugt. Ein solcher Operator führt ein nichtdeterministisches Ver- 
halten ein: wenn von mehreren Kanten gleichzeitig Daten eintreffen, dann ist die 
Reihenfolge der Abarbeitung dieser Daten nicht mehr festgelegt. Diese Erweiterung 
ist in der Praxis nützlich, sie macht aber die schönste Eigenschaft der KPNs zunichte. 

Im Allgemeinen benötigen KPNs ein Scheduling zur Laufzeit, da sich ihr genaues 
Verhalten nur schwer voraussagen lässt. Die Ursache dafür ist, dass wir keinerlei 
Annahmen über die Geschwindigkeiten von Kanälen und Knoten machen. Da aber in 
frühen Entwurfsphasen keinerlei Ausführungszeiten bekannt sind, ist dieses Modell 
für diese Phasen sehr gut geeignet. 

KPNs sind Turing-vollständig. Das bedeutet: alles, was mit einer Turing-Maschine 
(dem Standard-Modell der Berechenbarkeit) berechnet werden kann, kann auch mit 
einem KPN berechnet werden. Der Beweis basiert darauf, dass KPNs eine Ober- 
menge der Boolean Dataflow (BDF)-Netzwerke sind und nach Buck [73] können 
BDF-Netzwerke Turing-Maschinen simulieren. Eine Einschränkung der Anwendbar- 
keit von KPNs ergibt sich allerdings aus der Tatsache, dass die Anzahl der Prozesse 
in KPNs fest ist, sich also nicht zur Laufzeit ändert. 

Im allgemeinen Fall ist es unentscheidbar, ob FIFOs endlicher Länge für ein 
gegebenes KPN-Modell ausreichen. Eine Reihe praktisch anwendbarer Scheduling- 
Algorithmen für KPNs werden in [294] beschrieben. Auch gibt es für einige spezielle 
Fälle Beweise der Beschränkheit der Größe von FIFOs [99]. Beispielsweise können 
Schranken für den Spezialfall Polyhedral Process Networks (PPNs) bestimmt wer- 
den. Bei PPNs müssen die Grenzen aller Schleifen zur Compilezeit bekannt sein. 
Derin [125] nutzt Wissen über den Programmcode der Knoten für eine dynamische 
Verlagerung von Prozessen zwischen Prozessoren. 


2.5.3 SDF 


Wenn wir Beschränkungen für das Timing von Knoten und Kanälen zulassen, wird 
das Scheduling deutlich einfacher und außerdem lassen sich benötigte Puffergrößen 
bestimmen. Dies ist beim SDF-Modell der Fall [334]. SDF bedeutete ursprünglich 
Synchronous Data Flow bzw. synchroner Datenfluss, wird aber heute teilweise als 
Static Data Flow gedeutet. 

Das SDF-Modell [334] lässt sich am besten anhand seiner graphischen Darstel- 
lung erklären. Die Darstellung basiert auf einem gerichteten Graphen bestehend 
aus Knoten und gerichteten Kanten. Die Knoten werden auch als Aktoren (engl. ac- 
tors) bezeichnet. Die Kanten können Marken speichern, wobei die Speicherkapazität 
standardmäßig unbegrenzt ist. Im Allgemeinen werden manche der Kanten anfangs 
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Marken enthalten. Zu jeder Kante gehört eine Anzahl von konsumierten Marken 
(Zahl am Pfeilende der graphischen Darstellung) und eine Anzahl von erzeugten 
Marken (Zahl am anderen Ende der Kanten). Die Ausführung eines SDF-Modells 
geschieht taktgesteuert auf der Basis eines impliziten Taktgebers. Ein Aktor ist aus- 
führungsbereit, wenn für jede eingehende Kante die Zahl der vorhandenen Marken 
mindestens gleich der Zahl der zu konsumierenden Marken ist. 


Beispiel 2.21: Abb. 2.39 (links) zeigt einen SDF-Graphen. A und B stellen die Be- 
rechnungen dar. Für Aktor B gibt es eine ausreichende Anzahl von Marken auf der 
eingehenden Kante, sodass dieser ausführungsbereit ist. Aktor A ist nicht ausfüh- 
rungsbereit. Bei jedem Takt können die ausführungsbereiten Aktoren ausgeführt 


Abb. 2.39 SDF-Graph: links: Anfangssituation; rechts: nach Ausführung von B 


werden, sie müssen es aber nicht. Eine Ausführung bewirkt, dass für die Eingangs- 
kanten die Anzahl der Marken um die zu konsumierenden Marken reduziert werden. 
Ebenso bewirkt eine Ausführung, dass für die Ausgangskanten die Anzahl der aktu- 
ellen Marken um die Anzahl zu erzeugenden Marken erhöht werden. Im Beispiel ist 
die Veränderung der Anzahl der Marken in der Abb. 2.39 (rechts) zu sehen. V 


In der Praxis stellen Marken Daten dar, Aktoren repräsentieren Berechnungen und 
Kanten benötigen im Allgemeinen FIFO-Puffer. Diese Puffer implizieren, dass SDF 
asynchronen Nachrichtenaustausch benutzt. Anstelle der standardmäßig unbe- 
grenzten Pufferkapazitäten können wir begrenzte Pufferkapazitäten mit Hilfe von 
Rückwärtskanten modellieren. Die anfängliche Zahl der Marken auf den Rückwärts- 
kanten entspricht dabei der Kapazität der FIFO-Puffer. Dies wird in Abb. 2.40 
gezeigt. Die zwei gezeigten Modelle sind dabei äquivalent. 


Abb. 2.40 Ersetzen von expliziten FIFO-Puffern durch Rückwärtskanten 
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Beispielsweise wird die erste Ausführung von A drei Marken von der Rückwärts- 
kante konsumieren, sodass nur noch eine Marke auf dieser Kante verbleibt, was 
dem einen leeren FIFO-Platz nach der ersten Ausführung von A auf der linken Seite 
entspricht. 

Aufgrund der statischen Anzahl der erzeugten und der konsumierten Marken auf 
jeder Kante ist es möglich, eine Ausführungsreihenfolge und den Speicherbedarf zur 
Entwurfszeit zu bestimmen. Damit kann eine komplexe Bestimmung einer Ausfüh- 
rungsreihenfolge zur Laufzeit (ein dynamisches Scheduling) vermieden werden. Es 
ist möglich, aus SDF-Graphen periodische Ausführungsreihenfolgen zu erzeugen. 


Beispiel 2.22: Wir betrachten Ausführungsreihenfolgen (engl. schedules) von SDF- 
Graphen anhand des Modells in Abb. 2.41. Angenommen, es gäbe anfänglich sechs 


Abb. 2.41 SDF-Schleife 3 e 4 6 
65 — (2) ; 


Marken auf der Kante e;. Tabelle 2.2 (links) zeigt die resultierende Ausführungs- 
reihenfolge. Aufgrund der begrenzten Anzahl anfänglich vorhandener Marken ist 
nur eine sequentielle Ausführung möglich. Nunmehr nehmen wir an, es gäbe neun 


Tabelle 2.2 Schedule für SDF-Schleife: links: 6 initiale Marken, rechts: 9 initiale Marken 


Takt| Marken auf Kanten |Nächste Aktion Takt| Marken auf Kanten Nächste Aktion 
e e A oder B eı e A oder B oder (A und B) 
0 6 0 A 0 9 0 A 
1 3 2 A 1 6 2 A 
2 (0) 4 B 2 3 4 A und B 
3 6 0 A 3 6 2 A 
4 3 2 A 4 3 4 AundB 


initiale Marken auf der Kante e1. Unter der Annahme, dass alle Aktoren so früh wie 
möglich ausgeführt werden, ergibt sich die Ausführung gemäß Tabelle 2.2 (rechts). 
Unter dieser Annahme werden A und B gleichzeitig ausgeführt. V 


Bei der Erzeugung von Ausführungsreihenfolgen könnten wir auch Zielfunk- 
tionen und Beschränkungen berücksichtigen, wie beispielsweise eine beschränkte 
Anzahl von Prozessoren [57]. 

In obigem Beispiel führten die Kantengewichte 2, 3, 4 und 6 zu unterschiedlichen 
Ausführungsraten der Aktoren A und B. Im Allgemeinen erlauben Kantengewichte 
die Modellierung von Mehrraten-Signalverarbeitungsanwendungen, d.h. Anwendun- 
gen, bei denen bestimmte Signale mit Raten erzeugt werden, die ein Vielfaches der 
Raten anderer Signale sind. Beispielsweise könnten in einem Fernsehgerät manche 
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Berechnungen mit einer Rate von 100 Hz erzeugt werden, wohingegen andere Signa- 
le mit einer Rate von 50 Hz erzeugt werden. Abgesehen von der Initialisierungsphase 
und über längere Perioden betrachtet, muss dabei in einem SDF-Graphen die Anzahl 
der Marken, die an eine Kante gesendet werden gleich der Anzahl der Marken sein, 
die von dieser Kante wieder abgezogen werden. Ansonsten würden sich Marken 
in den FIFO-Puffern ansammeln und keine endliche FIFO-Kapazität würde jemals 
ausreichen. Sei n, die Anzahl von Marken, die durch die Ausführung eines senden- 
den Aktors s erzeugt werden und sei f; die Ausführungsrate. Sei n, die Anzahl von 
Marken, die durch die Ausführung eines empfangenden Aktors r konsumiert werden 
und sei f die Ausführungsrate. Dann muss gelten 


Ns * fs = Ny * Fr (2.13) 


In Tabelle 2.2 ist diese Bedingung für den stationären Zustand erfüllt. 
SDF-Graphen können auch Verzögerungen enthalten, was durch das das Symbol 
D auf einer Kante dargestellt wird (siehe Abb. 2.42). 


Abb. 2.42 Verzögerung in SDF 


Das Observer-Muster, für das wir bei der Modellierung mit von-Neumann- 
Sprachen ein Problem hatten (siehe Seite 37), kann in SDF relativ leicht korrekt 
modelliert werden (siehe Abb. 2.43). Es gibt kein Risiko von Deadlocks. Allerdings 
erlaubt es SDF auch nicht, zur Laufzeit neue Beobachter hinzuzufügen. 


Abb. 2.43 Observer-Muster in SDF 


Der Buchstabe „S” in SDF stand ursprünglich für das Adjektiv synchronous, 
da ausführbereite Aktoren synchron ausgeführt werden können. Allerdings zeigen 
die Ausführungsreihenfolgen in Tabelle 2.2, dass das gleichzeitige Ausführen aller 
Aktoren tatsächlich eher selten sein kann. Deswegen wird das „S” inzwischen auch 
so interpretiert, dass es für das Adjektiv static steht, denn eine mögliche statische 
Planung der Ausführungsreihenfolge ist in der Tat ein wesentliches Merkmal von 
SDF. 
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SDF-Modelle sind deterministisch (siehe Haubelt et al. [207], Abschnitt 2.2), 
eignen sich aber nicht fiir die Modellierung von Kontrollfliissen wie z.B. Spriingen. 
Einige Erweiterungen von SDF-Modellen wurden vorgeschlagen (siehe z.B. Stuijk 
[515]): 


e Eine Ergänzung sind Modi, die den Zuständen eines zugehörigen endlichen Au- 
tomaten entsprechen. Für jeden Modus könnte jeweils ein anderer SDF-Graph zu- 
treffend sein. Ein Übergang zwischen diesen Modi könnte dann durch bestimmte 
Ereignisse erfolgen. 

e Homogene synchrone Datenflussgraphen (engl. Homogeneous Synchronous 
Data Flow (HSDF)) sind ein Spezialfall von SDF-Graphen. Bei diesen beträgt 
die Anzahl der pro Ausführung erzeugten und verbrauchten Marken jeweils 1. 

e Bei zyklo-statischem Datenfluss (engl. Cyclo-Static Data Flow (CSDF)) kann 
die Anzahl der pro Ausfiihrung erzeugten und verbrauchten Marken zeitlich 
variieren, aber es muss insgesamt ein periodisches Verhalten vorliegen. 


2.5.4 Simulink 


Graphenstrukturen für Berechnungen werden auch häufig in der Regelungstechnik 
eingesetzt. In diesem Bereich ist die Simulink®-Komponente von MATLAB® weit 
verbreitet. MATLAB/Simulink [529] ist ein Modellierungs- und Simulationswerk- 
zeug, das auf mathematischen Prinzipien beruht. Abb. 2.44 zeigt ein Beispiel fiir ein 
Simulink-Modell [366]. 


G) traio 
teta_in 
teta10 ()— stick_cmd 
pitch_mode 
€ ) teta0 f elevator 
stick_com control 
teta0 not_teta [A] 
sticks 
teta_com_select goto - 
sticks = 
elev_com 1.1235 
€ — d i ae 
on 4 Gain6 Saturation 
speed_com Speed_com 
OD Ve_sens | teta_com 
Vc_sens A > | 
œ ineg_rst 
A - pitch_net 
IA] air_speed_net 


From 


Abb. 2.44 Simulink®-Modell 
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Der Verstärker Gain6 und die Sattigungskomponente Saturation zeigen, dass hier 
analoge Modellierungskomponenten einbezogen werden können. Die ,,Schaltung” 
könnte hier auch Symbole enthalten, die für analoge Komponenten wie Integratoren 
oder Differentiatoren stehen. Der in der Mitte der Abbildung zu sehende Schalter 
zeigt, dass sich mit Simulink auch Kontrollflüsse modellieren lassen. 

Diese graphische Darstellung ist intuitiv und ermöglicht es Ingenieuren der Re- 
gelungstechnik, einen Schwerpunkt auf die Regelungsfunktion zu legen, ohne den 
für die Implementierung dieser Funktion benötigten Code zu berücksichtigen. Die 
graphischen Symbole verdeutlichen dabei, dass analoge Schaltungen traditionell als 
Komponenten von Regelkreisentwürfen vorkommen. Ein Hauptziel ist es, aus sol- 
chen Entwürfen Software zu erzeugen. Dieser Ansatz wird meistens mit dem Begriff 
modellgetriebener Entwurf verbunden. 

Die Semantik von Simulink-Modellen entspricht der Simulation auf einem di- 
gitalen Computer. Damit ist das Verhalten ähnlich zu dem analoger Schaltungen, 
aber möglicherweise nicht identisch dazu. Was ist also im Endeffekt die Semantik 
eines Simulink-Modells? Marian und Ma [366] beschreiben die Semantik wie folgt: 
„Simulink verwendet ein idealisiertes Zeitmodell für die Ausführung von Blöcken 
(Knoten) und die Kommunikation. Beide werden zu fest vorgegebenen Zeitpunkten 
in der Simulation mit unendlicher Geschwindigkeit ausgeführt. Danach wird die 
Simulationszeit um genau bestimmte Zeiteinheiten erhöht. Zwischen den einzelnen 
Zeitschritten sind alle Werte auf den Kanten konstant’. Das bedeutet, dass das Mo- 
dell schrittweise ausgeführt wird. In jedem Schritt wird die Funktion der Knoten (in 
Nullzeit) berechnet und die neuen Ergebnisse an den mit diesen verbundenen Ein- 
gängen zur Verfügung gestellt. Diese Erklärung legt keinen Abstand zwischen den 
Zeitschritten fest. Auch ist nicht direkt offensichtlich, wie sich ein solches System in 
Software implementieren lässt, da es vorkommen kann, dass auch nur sich langsam 
verändernde Ausgangswerte regelmäßig neu berechnet werden müssen. 

Dieser Ansatz ist gut geeignet, um physische Systeme, z.B. Verkehrsmittel, zu 
modellieren und dann deren Verhalten zu simulieren. Auch digitale Signalverar- 
beitungssysteme können bequem in MATLAB modelliert werden. Um eine reale 
Implementierung eines MATLAB/Simulink-Modells zu erhalten, muss es erst in 
eine Sprache übersetzt werden, die von Hardware- oder Softwareentwurfssystemen 
unterstützt wird, also beispielsweise in C oder VHDL. 

Die Komponenten von Simulink-Modellen stellen einen Spezialfall von Aktoren 
dar. Wir können dabei annehmen, dass Aktoren auf Eingaben warten und ihre Ope- 
rationen erst durchführen, wenn alle benötigten Eingaben vorhanden sind. SDF ist 
ein weiteres Beispiel für aktorbasierte Sprachen. In aktorbasierten Sprachen ist es, 
im Gegensatz zu von-Neumann-Sprachen, nicht erforderlich, den Aktoren explizit 
einen Kontrollfluss zuzuweisen. 
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2.6 Petrinetze 


2.6.1 Einfiihrung 


Eine sehr umfassende Beschreibung von Kontrollfliissen ist mit den als Petrinetzen 
bezeichneten Berechnungsgraphen möglich. Genau genommen modellieren Petri- 
netze ausschließlich Kontrollmechanismen und Kontrollabhängigkeiten. Die gleich- 
zeitige Modellierung von Daten ist nur durch Erweiterungen von Petrinetzen reali- 
sierbar. Der Schwerpunkt von Petrinetzen liegt also auf der Modellierung kausaler 
Abhängigkeiten. 

Im Jahr 1962 veröffentlichte Carl Adam Petri seine Methoden zur Darstellung 
kausaler Abhängigkeiten [450], die unter dem Namen Petrinetze bekannt wurden. 
Petrinetze gehen nicht von einer globalen Synchronisation aus und sind daher be- 
sonders gut zur Modellierung verteilter Systeme geeignet. 

Bedingungen, Ereignisse und eine Flussrelation sind die Kernelemente von 
Petrinetzen. Bedingungen sind entweder erfüllt oder nicht erfüllt, Ereignisse können 
eintreten. Die Flussrelation beschreibt die Bedingungen, die erfüllt sein müssen, 
damit Ereignisse eintreten können. Außerdem beschreibt sie, welche Bedingungen 
wahr werden, wenn ein Ereignis eintritt. Graphische Darstellungen von Petrinetzen 
verwenden typischerweise Kreise, um Bedingungen darzustellen und Rechtecke, um 
Ereignisse darzustellen. Pfeile stellen die Flussrelation dar. 


Beispiel 2.23: Abb. 2.45 zeigt eine Modellierung von Zugverkehr als Petrinetz. Es 
beschreibt den gegenseitigen Ausschluss von Zügen auf einem eingleisigen Strecken- 
abschnitt, der in beide Richtungen befahren werden muss. Ein Token oder eine Marke 


Zug fährt von links ein Zug fährt nach rechts aus 
: Zug fährt 
Zug will nach rechts Y nach rechts Ý 


>| 


=o 


Gleis frei 


O 


= 
Zug fährt 

nach links 

<— eingleisig <— 


Abb. 2.45 Eingleisiger Abschnitt einer Bahnstrecke 


wird verwendet, um die Kollision von Zügen zu vermeiden, die in unterschiedliche 
Richtungen fahren. Im Beispielnetz wird das Token durch eine erfüllte Bedingung in 
der Mitte des Modells dargestellt. Der kleine, im großen Kreis enthaltene ausgefüllte 
Kreis symbolisiert die Situation, in der die Bedingung erfüllt ist (im Beispiel: der 
Abschnitt ist frei). Dementsprechend kennzeichnet eine weitere Marke die Tatsache, 
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dass ein Zug nach rechts fahren möchte. Damit sind die beiden Bedingungen zum 
Schalten des Ereignisses „Zug fährt nach rechts“ erfüllt. Wir nennen diese Bedin- 
gungen Vorbedingungen. Wenn die Vorbedingungen eines Ereignisses erfüllt sind, 
kann das Ereignis eintreten. 

Nach dem Eintreten des Ereignisses ist die Marke nicht mehr verfügbar und es 
wartet kein Zug mehr auf den eingleisigen Abschnitt. Folglich sind die Vorbedingun- 
gen nicht mehr erfüllt und die ausgefüllten Kreise verschwinden (siehe Abb. 2.46). 
Andererseits fährt jetzt ein Zug auf dem Abschnitt von links nach rechts. Somit ist 


Zug fährt von links ein Zug fährt nach rechts heraus 


i ' Zug fahrt : 
Zug will nach rechts Y nach rechte. ii 


Os OF 


Gleis verfügbar 


Log OTe OS 
Zug fahrt 
nach links 


Abb. 2.46 Verwendung der Ressource „Gleisabschnitt“ 


die zugehörige Bedingung erfüllt. Eine Bedingung, die nach dem Eintreten eines 
Ereignisses erfüllt ist, heißt Nachbedingung. Im Allgemeinen kann ein Ereignis 
nur dann eintreten, wenn alle seine Vorbedingungen erfüllt sind. Wenn das Ereignis 
eingetreten ist, sind die Vorbedingungen nicht mehr erfüllt, stattdessen werden die 
Nachbedingungen erfüllt. Die Vor- und Nachbedingungen eines Ereignisses werden 
durch Pfeile dargestellt. 

Ein Zug, der den eingleisigen Streckenabschnitt verlässt, stellt die Marke in der 
Mitte des Modells wieder her (siehe Abb. 2.47). 


Zug fährt von links ein Zug fährt nach rechts heraus 
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Abb. 2.47 Freigabe der Ressource „Gleisabschnitt“ 
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Wenn zwei Ziige gleichzeitig den eingleisigen Abschnitt benutzen wollen (siehe 
Abb. 2.48), kann nur einer der beiden in den Abschnitt eintreten. 


Zug fährt von links ein Zug fährt nach rechts heraus 
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Abb. 2.48 Konflikt um die Ressource „Gleisabschnitt“ vV 


In solchen Situationen wird das nächste Ereignis nichtdeterministisch ausgewählt. 
Netzanalysen müssen dabei alle möglichen Folgen von Ausführungen von Ereignis- 
sen berücksichtigen. Bei Petrinetzen modellieren wir absichtlich Nichtdeterminis- 
mus. 

Ein wichtiger Vorteil von Petrinetzen liegt darin, dass sie als Grundlage für forma- 
le Beweise von Systemeigenschaften dienen können. Es existieren bereits einige Stan- 
dardmethoden, um solche Beweise automatisch zu erzeugen. Um diese Beweise zu 
ermöglichen, benötigen wir eine formalere Definition von Petrinetzen. Wir betrach- 
ten drei Klassen von Petrinetzen: Bedingungs/Ereignis-Netze, Stellen/Transitions- 
Netze und Prädikat/Ereignis-Netze. 


2.6.2 Bedingungs/Ereignis-Netze 


Als erste Klasse von Petrinetzen werden wir Bedingungs/Ereignis-Netze formal 
definieren. 


Definition 2.15: N = (C, E, F) heißt Netz, genau dann, wenn die folgenden Bedin- 
gungen erfüllt sind: 


1. C und E sind disjunkte Mengen. 
2. F C (E x C) U (C x E) ist eine zweistellige Relation, genannt Flussrelation. 


Die Menge C heißt die Menge der Bedingungen und die Menge E ist die Menge der 
Ereignisse (auch Transitionen genannt). 


Definition 2.16: Sei N ein Netz und sei x € (CUE). Dann heißt °x := {y|yFx,y € 
(CU E)} der Vorbereich von x. Wenn x ein Ereignis ist, dann heißt °x auch „Menge 
der Vorbedingungen von x”. 
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Definition 2.17: Sei N ein Netz und sei x € (C U E). Dann heißt x° := {y|xFy,y € 
(CUE)} der Nachbereich von x. Wenn x ein Ereignis ist, dann heißt x° auch „Menge 
der Nachbedingungen von x”. 


Die Begriffe Vorbedingung und Nachbedingung werden in den Fällen bevorzugt, in 
denen diese Mengen tatsächlich Bedingungen € C darstellen, also x € E gilt. 


Definition 2.18: Sei (c,e) € C x E. (c,e) heißt Schleife, wenn cFe A eF c. 


Definition 2.19: Sei (c,e) € C x E. N heißt rein, wenn F keine Schleifen enthält 
(siehe Abb. 2.49 (links)). 


oe 2 


Abb. 2.49 Netze, die nicht rein (links) und nicht einfach sind (Mitte und rechts) 


Definition 2.20: Ein Netz heißt einfach, wenn keine zwei Transitionen 7; und h die 
gleiche Menge von Vor- und Nachbedingungen haben (siehe Abb. 2.49 (Mitte) und 
(rechts)). 


Einfache Netze ohne isolierte Elemente, die einige zusätzliche Anforderungen 
erfüllen, heißen Bedingungs/Ereignis-Netze. Bedingungs/Ereignis-Netze sind ein 
Sonderfall von bipartiten Graphen (Graphen mit zwei unterschiedlichen, disjunkten 
Mengen von Knoten). Die zusätzlich notwendigen Bedingungen werden wir hier 
nicht weiter vertiefen, da wir uns im Weiteren mit allgemeineren Klassen von Netzen 
beschäftigen. 


2.6.3 Stellen/Transitions-Netze 


Bei Bedingungs/Ereignis-Netzen gibt es höchstens eine Marke (engl. token) pro 
Bedingung. Für viele Anwendungen ist es nützlich, diese Einschränkung aufzuheben 
und mehrere Marken pro Bedingung zu erlauben. Netze, die mehrere Marken pro 
Bedingung erlauben, heißen Stellen/Transitions-Netze (engl. place/transition nets). 
Stellen entsprechen den bisher verwendeten Bedingungen, Transitionen entsprechen 
den Ereignissen. Die Anzahl von Marken pro Stelle heißt Belegung. Mathematisch 
betrachtet ist eine Belegung eine Abbildung von der Menge der Stellen auf die Menge 
der natürlichen Zahlen, die um ein besonderes Symbol erweitert wird: w steht für 
unendlich. 

Sei No die Menge der natürlichen Zahlen inklusive der 0. Ein Stellen/Transiti- 
onen-Netz kann formal wie folgt definiert werden: 
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Definition 2.21: (P,T,F,K,W,Mo) heißt Stellen/Transitions-Netz genau dann, 
wenn 


1. N = (P,T, F) ein Netz ist, mit den Stellen p € P und den Transitionen t € T, 

2. die Abbildung K : P — (No U {w}) \ {0} die Kapazität der Stellen darstellt 
(wobei w eine unbeschränkte Kapazität symbolisiert), 

3. die Abbildung W : F — (No \ {0}) das Gewicht der Kanten des Graphen darstellt 

4. und die Abbildung Mọ : P — No U {œ} die initiale Belegung der Stellen mit 
Marken darstellt. 


Kantengewichte haben einen Einfluss auf die Anzahl der Marken, die benötigt wer- 
den, bevor eine Transition schalten kann und geben auch die Anzahl von Marken 
an, die von einer schaltenden Transition erzeugt werden. Sei M(p) die aktuelle Be- 
legung der Stelle p € P und sei M’(p) die Markierung nach dem Schalten einer 
Transition t € T. Das Gewicht der Kanten, die zu Vorbedingungen von f gehören, 
gibt die Anzahl der Marken an, die aus den Vorbedingungs-Stellen abgezogen wer- 
den. Entsprechend stellt das Gewicht der Kanten, die zu Nachbedingungen führen, 
die Anzahl der Marken dar, die den Stellen in den Nachbedingungen hinzugefügt 
werden. Formal wird die neue Belegung M’ wie folgt berechnet: 


M(p) - W(p,t), falls p € °t\ r 

M'(p) = M(p) + W(t, p), falls pe t£ \ °t 

á M(p) - W(p,t) + W(t, p), falls pe *t t° 
M(p) sonst 


Abb. 2.50 zeigt ein Beispiel, wie sich das Schalten von Transition t; auf die aktuelle 
Markierung auswirkt. 
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Abb. 2.50 Erzeugung einer neuen Markierung 


Für unbeschriftete Kanten vereinbart man ein Gewicht von 1 und Knoten ohne 
entsprechende Angabe haben eine unbeschränkte Kapazität w. 

Jetzt müssen noch die beiden Bedingungen beschrieben werden, die erfüllt sein 
müssen, bevor eine Transition t € T schalten kann: 


e inallen Stellen p in der Menge der Vorbedingungen muss die Anzahl der Marken 
mindestens so groß sein wie das Gewicht der Kante von p nach r und 

e in allen Stellen p in der Menge der Nachbedingungen muss die Kapazität groß 
genug sein, um die von f neu erzeugten Marken aufzunehmen. 
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Formal kann dies wie folgt definiert werden: 


Definition 2.22: Transition t € T heißt M-aktiviert, wenn sie die folgende komplexe 
Bedingung erfüllt: 


(Vp € °t: M(p) = W(p,t)) A (Vp’ € t* : M(p’) + W(t,p’) < K(p’)) 


Aktivierte Transitionen können schalten, müssen dies aber nicht zwangsläufig. Wenn 
mehrere Transitionen aktiviert sind, ist die Reihenfolge ihres Schaltens nicht deter- 
ministisch definiert. 

Der Einfluss einer schaltenden Transition t auf die Markenzahl kann bequem 
durch einen der Transition zugeordneten Vektor t beschrieben werden, der wie folgt 
definiert ist: 


—W(p,t), falls pe °r\ f° 
i(Gi= +W(t,p), fallspe t \ °*t 
= -W(p,t) + W(t,p), falls pe "tn t° 

0 sonst 


Beim Schalten einer Transition ¢ ergibt sich dann die neue Markenzahl M’ für alle 
Stellen p wie folgt: 


M’(p) = M(p) + t(p) 


Unter Benutzung der Vektoraddition können wir verkürzt schreiben: 
M'=M+t 


Aus der Menge aller Vektoren können wir eine sogenannte Inzidenzmatrix N bilden, 
welche als Spalten die Vektoren der verschiedenen Transitionen enthält: 


N:PXT >Z; VteT:N(pt)=t(p) 


Mit Hilfe dieser Matrix kann man auf standardisierte Weise formale Beweise von 
Systemeigenschaften führen. Beispielsweise kann es Teilmengen der Stellen geben, 
in denen sich die Gesamtzahl der Marken unabhängig von den schaltenden Transitio- 
nen nicht verändert [468]. Solche Stellenmengen konstanter Markensumme nennen 
wir S-Invarianten. Um solche S-Invarianten zu finden, betrachten wir zunächst eine 
Transition t; und suchen Stellenmengen R C P, für die das Schalten der Transition 
die Markenzahl nicht verändert. Für diese muss gelten: 


1,0) = 0 (2.14) 


peR 


Abbildung 2.51 zeigt ein Beispiel für eine Transition, bei der für die drei Stellen 
die Markensumme konstant bleibt. 


90 2 Spezifikation und Modellierung 


Abb. 2.51 Transition mit konstanter Markensumme 
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Zur Vereinfachung der Summenschreibweise in Gleichung (2.14) führen wir nun- 
mehr den sogenannten charakteristischen Vektor c, einer Stellenmenge R ein: 


_ |1wennpeR 
Er(P) = is wenn p ¢ R 
Mit dieser Definition können wir Gleichung (2.14) umschreiben zu: 
Yo Hei (2.15) 
peR peP 


Dabei kennzeichnet - das Skalarprodukt. Wir suchen jetzt Stellenmengen, für die 
das Schalten aller Transitionen die Markensumme konstant lässt. Dann muss die 
Gleichung (2.15) statt für eine Transition t; für alle Transitionen gelten: 


Cr =0 
ty + Cp =0 (2.16) 
I, Cr =0 


Das Gleichungssystem (2.16) lässt sich mit der transponierten Inzidenzmatrix NT 
zusammenfassen zu: 


NT +6, =0 (2.17) 


Das Gleichungssystem (2.17) ist ein lineares homogenes Gleichungssystem. Die 
Matrix N beschreibt die Kantengewichte des Petrinetzes. Gesucht sind Vektoren c R? 
welche dieses Gleichungssystem lösen. Da die Lösungsvektoren charakteristische 
Vektoren sein müssen, können wir als Komponenten der Vektoren nur O und 1 
erlauben!5. Das Lösen derartiger Gleichungssysteme ist komplexer als das Lösen 
von Gleichungssystemen mit reellwertigen Lösungsvektoren. Dennoch können durch 
das Lösen von Gleichung (2.17) Aussagen über Eigenschaften eines Petrinetzes 
gewonnen werden. In unserem Beispiel ändert sich die Anzahl der Züge, die zwischen 
Köln und Paris verkehren, nicht. Das gleiche gilt für die Züge zwischen Amsterdam 
und Paris. In Modellen, die den Zugriff auf gemeinsame Ressourcen modellieren, 
kann beispielsweise der gegenseitige Ausschluss nachgewiesen werden. 


15 Wenn wir gewichtete Markensummen betrachten, können wir natürliche Zahlen als Lösungen 
erlauben. 
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Beispiel 2.24: Wir betrachten nun ein größeres Beispiel: Wieder geht es um die 
Synchronisation von Zügen, in diesem Fall werden die Hochgeschwindigkeitszüge 
vom Typ ‚„Thalys” modelliert, die zwischen Amsterdam, Köln, Brüssel und Paris 
verkehren. Es gibt unabhängige Zugteile, die von Amsterdam und Köln nach Brüssel 
fahren. Dort werden die Zugteile verbunden und fahren dann gemeinsam nach Paris 
weiter. Auf dem Rückweg von Paris werden die Züge in Brüssel wieder getrennt. 
Wir nehmen an, dass die Züge in Paris Anschlüsse an Züge aus dem Pariser Süden 
sicherstellen müssen. Das zugehörige Petrinetz zeigt Abb. 2.52. 
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Abb. 2.52 Modell der Thalys-Züge zwischen Amsterdam, Köln, Brüssel und Paris 


Paris 
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Sofern die Bedingungen gemäß Stellen 3 und 10 erfüllt sind, modellieren sie Züge, 
die in Amsterdam bzw. Köln warten. Die Transitionen 9 und 2 bilden Züge nach, die 
von diesen Städten aus nach Brüssel fahren. Nach der Ankunft in Brüssel enthalten 
die Stellen 9 und 2 jeweils eine Marke. Transition 1 symbolisiert das Verbinden der 
beiden Zugteile. Die Bedingung gemäß Stelle 13 ist erfüllt, sofern einer der beiden 
Lokführer in Brüssel eine Pause hat, während der andere nach Paris weiterfährt. 
Transition 5 stellt die Anschlussbedingungen mit anderen Zügen im Gare du Nord 
von Paris dar. Diese Anschlüsse verbinden den Gare du Nord mit anderen Pariser 
Bahnhöfen (wir haben hier lediglich den Gare de Lyon als Beispiel gezeigt, obwohl 
es in Paris noch weitere Bahnhöfe gibt). Selbstverständlich fahren die Thalys-Züge 
nicht mit Dampflokomotiven — die verwendeten Symbole sind aber eingängiger als 
die von modernen Hochgeschwindigkeitszügen. Tabelle 2.3 enthält die Matrix NT 
für dieses Beispiel. 
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Tabelle 2.3 NT für das Thalys-Beispiel 


P1|P2|P3|P4|P5 |P6|P7|P8|P9|P10|P11 \Pı2|Pı3 
t |1 J-l -1 1 

to 1 |-1 
t3 1 |-1 


In diesem Beispiel ist in Zeile 2 dargestellt, dass das Schalten von tz die Anzahl der 
Marken bei p? um eine erhöht und die Anzahl der Marken bei p3 um eine vermindert. 
Unter Einsatz von Methoden der linearen Algebra können wir zeigen, dass die 
folgenden vier Vektoren Lösungen dieses linearen Gleichungssystems darstellen: 

cr,1 = (1,1,1,1,1,1,0,0,0,0,0,0,0) 
cr,2 = (1,0,0,0,1,1,0,0,1,1,1,0,0) 
cr,3 = (0,0,0,0,0,0,0,0,1,1,0,0, 1) 
cr,4 = (0,0,0,0,0,0,1,1,0,0,0, 1,0) 

Diese Vektoren entsprechen den Orten entlang der Gleise für Züge aus Köln 
und Amsterdam sowie den Orten entlang des Weges für Lokführer von Zügen aus 
Amsterdam und den Orten entlang der Gleise innerhalb von Paris. Damit können 
wir zeigen, dass die Anzahl von Zügen und Lokführern entlang der Gleise konstant 
ist (was wir natürlich erwartet haben). Dieses Beispiel zeigt, dass S-Invarianten 
als Standardtechnik eingesetzt werden können, um Eigenschaften von Systemen zu 
beweisen. V 


2.6.4 Prädikat/Transitions-Netze 


Sowohl Bedingungs/Ereignis-Netze als auch Stellen/Transitions-Netze können für 
größere Beispiele schnell sehr groß und unübersichtlich werden. Eine Verringerung 
der Größe ist häufig durch den Einsatz von Prädikat/Transitions-Netzen möglich. 


Beispiel 2.25: Wir werden dies am Beispiel der „dinierenden Philosophen“ demons- 
trieren. Das Problem geht von einer Anzahl von Philosophen aus, die an einem runden 
Tisch essen. Vor jedem Philosophen steht ein Teller mit Spaghetti (siehe Abb. 2.53). 
Zwischen den Tellern befindet sich jeweils nur eine Gabel. Jeder Philosoph ist ent- 
weder mit Essen oder mit Nachdenken beschäftigt. Essende Philosophen benötigen 
dafür die beiden Gabeln, die neben ihrem Teller liegen. Folglich kann ein Philosoph 
nur dann essen, wenn seine beiden Nachbarn gerade nicht essen. 
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Abb. 2.53 Das Problem der dinierenden Philosophen 4 


Diese Situation kann, wie in Abb. 2.54 gezeigt, in einem Bedingungs/Ereignis-Netz 
modelliert werden. 
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Abb. 2.54 Bedingungs/Ereignis-Netz des Philosophen-Problems 


Die Bedingungen t; entsprechen dem „denkenden“, die Bedingungen e; dem 
„essenden“ Zustand und die Bedingungen f; stellen die verfügbaren Gabeln dar. In 
Anbetracht der geringen Größe des zugrundeliegenden Problems ist dieses Netz be- 
reits recht groß. Das Netz lässt sich verkleinern, wenn man ein Prädikat/Transitions- 
Netz verwendet. Abb. 2.55 zeigt ein Modell des Philosophen-Problems als Prädi- 
kat/Transitions-Netz. Bei Prädikat/Transitions-Netzen haben Marken eine Identität 
und können unterschieden werden. Man kann sich dies auch als Kennzeichnung der 
Marken durch Farben vorstellen. Daher heißen diese Netze im Englischen auch 
Coloured Petri Nets (CPN) [273]. Die Identität wird in Abb. 2.55 benutzt, um die 
drei Philosophen pı bis p3 zu unterscheiden und um die Gabel f zu identifizieren. 
Des weiteren können Kanten mit Beschriftungen versehen werden, die Variablen 
und Funktionen repräsentieren. Im Beispiel werden Variablen verwendet, um die 
Identität der Philosophen zu beschreiben. Die Funktionen /(x) bzw. r(x) beschrei- 
ben die linke bzw. rechte Gabel von Philosoph x. Diese beiden Gabeln werden als 
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Abb. 2.55 Prädikat/Transitions-Netz 
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Vorbedingung für die Transition u benötigt und sie werden als Nachbedingung beim 
Schalten der Transition v wieder zurückgegeben. Dieses Modell kann einfach durch 
das Hinzufügen weiterer Marken auf den Fall von n > 3 Philosophen erweitert 
werden. Im Gegensatz zu dem Netz in Abb. 2.54 muss die eigentliche Struktur des 
Netzes dazu nicht verändert werden. V 


2.6.5 Bewertung 


Der Hauptvorteil von Petrinetzen ist ihre Stärke bei der Modellierung kausaler Ab- 
hängigkeiten. Standard-Petrinetze bieten keine Unterstützung für Zeitbedingungen. 
Alle Entscheidungen können lokal getroffen werden, indem Transitionen mit ihren 
Vor- und Nachbedingungen analysiert werden. Aus diesem Grund können sie zur Mo- 
dellierung von geographisch verteilten Systemen verwendet werden. Außerdem gibt 
es starke theoretische Grundlagen für die Betrachtung von Petrinetzen, was formale 
Beweise von Systemeigenschaften vereinfacht. Petrinetze sind nicht notwendiger- 
weise deterministisch: unterschiedliche Schaltreihenfolgen können zu unterschied- 
lichen Ergebnissen führen. Die Beschreibungsstärke von Petrinetzen entspricht von 
der Stärke her der anderer Berechnungsmodelle inklusive endlicher Automaten. 

In manchen Zusammenhängen sind die Stärken von Petrinetzen aber auch ih- 
re Schwächen. Wenn Zeitbedingungen zu berücksichtigen sind, können Standard- 
Petrinetze nicht verwendet werden. Außerdem bieten diese kein Hierarchiekonzept 
und keine Programmiersprachenkonstrukte an, von objektorientierten Konzepten 
ganz abgesehen. In der Regel ist es schwierig, Daten in Petrinetzen darzustellen. 

Es gibt Erweiterungen von Petrinetzen, die einige dieser Schwächen beheben. 
Allerdings gibt es keine universelle Petrinetz-Erweiterung, die alle Anforderungen, 
die am Anfang dieses Kapitels aufgestellt wurden, erfüllt. Trotzdem haben sich 
Petrinetze aufgrund der zunehmenden Anzahl verteilter Systeme in der ganzen Welt 
zunehmend verbreitet. 

UML beinhaltet erweiterte Petrinetze unter der Bezeichnung Aktivitätsdiagram- 
me. Diese ergänzen Petrinetze um Symbole, die Entscheidungen kennzeichnen (wie 
in gewöhnlichen Flussdiagrammen). Die Platzierung der Symbole erfolgt ähnlich zu 
SDL. 
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Beispiel 2.26: Ein Beispiel dafiir ist in Abb. 2.56 zu sehen. Das Beispiel zeigt die 
während eines Standardisierungsprozesses durchzuführenden Vorgänge. Verzwei- 
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Abb. 2.56 Aktivitätsdiagramm [300] 


gungen und Vereinigungen des Kontrollflusses entsprechen den Transitionen in Pe- 
trinetzen, deren Symbole sie auch verwenden (horizontale Balken). Die am unteren 
Ende der Abbildung zu sehende Raute steht für eine Entscheidung. Aktivitäten las- 
sen sich in Bahnen ordnen (Flächen zwischen den gestrichelten Linien), damit lassen 
sich die unterschiedlichen Zuständigkeiten und die ausgetauschten Dokumente vi- 
sualisieren. V 


Es ist interessant zu sehen, dass Petrinetze ursprünglich nicht weit verbreitet waren 
und erst Jahre nach ihrer Erfindung durch die Verwendung in UML zu einer häufig 
angewendeten Modellierungstechnik wurden. 
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2.7 Diskrete, ereignisbasierte Sprachen 


2.7.1 Simulationszyklus diskreter Ereignissysteme 


Das diskrete, ereignisbasierte Berechnungsmodell basiert auf der Simulation der 
Erzeugung und Verarbeitung von Ereignissen im Zeitverlauf. Es verwendet eine 
Warteschlange zukünftiger Ereignisse, die nach der Zeit sortiert sind, zu der sie 
bearbeitet werden sollen. Die Semantik definiert, dass Ereignisse, die zum aktuel- 
len Zeitpunkt stattfinden sollen, aus der Warteschlange entfernt werden, die ihnen 
zugeordneten Aktionen ausgeführt werden und bei Bedarf neue Ereignisse zur War- 
teschlange hinzugefügt werden können. Die Zeit schreitet weiter fort, wenn für den 
aktuellen Zeitpunkt keine weitere Aktion definiert ist. Dies ist das Grundmodell der 
Simulation: 


loop 

Hole das nächste Ereignis aus der Warteschlange; 

Führe die Aktion aus, die mit dem Ereignis definiert ist 

(z.B. eine Variablenzuweisung; dabei können neue Ereignisse entstehen); 
until das Abbruchkriterium ist erfüllt; 


Verbreitete Hardwarebeschreibungssprachen (engl. Hardware Description Lan- 
guages (HDLs)) basieren meist auf dem diskreten Ereignismodell. Wir werden HDLs 
als ein bekanntes Beispiel der Modellierung auf der Basis eines diskreten Ereignis- 
systems nutzen. 


Beispiel 2.27: Die Anwendung des allgemeinen Simulationsschemas kann am Bei- 
spiel der Simulation eines RS-Flipflops demonstriert werden (siehe Abb. 2.57). 


>=> a gatel: nQ a gate2: 
process(a,b) process (a,b) Q 
begin c begin c 
c <= anor D; c <= anor b; 
BEEZ end; m> b end; 
R 


Abb. 2.57 RS-Flipflop aus zwei NOR-Gattern 


Die Schaltung besteht aus zwei kreuzweise verbundenen NOR-Gattern. Die Abbil- 
dung zeigt auch dazu gehörigen Code in einer HDL, in diesem Fall VHDL. 

Tabelle 2.4 enthält eine repräsentative Folge von Ein- und Ausgabewerten zu 
dieser Schaltung. Wir nehmen an, dass das Flipflop zunächst gesetzt ist und dass 
dieser Zustand gehalten wird, d.h. Q ist '1' und R = S = '®'. Prozesse gate1 
und gate2 beschreiben das Verhalten der beiden NOR-Gatter. Diese Prozesse sind 
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Tabelle 2.4 Folge von Werten an t<0| t=0 t>0 
Ein- und Ausgängen eines RS- R) 'Q! 'y! "4! ni >18 
Flipflops S '9! 'Q' 'Q' "9! "9! 


Q "4! Ra '9! '9' 'Q' 
nQ 'Q' 'Q' 'Q' 4! it 


zunächst inaktiv, während sie auf Ereignisse an den Eingängen a oder b warten. 
Dieses Warten wird durch die Listen (a,b) ausgedrückt. Man sagt, gatel und 
gate2 seien sensitiv bezüglich der Einträge in der Liste. 

Angenommen, zur Zeit 0 ändern wir den Wert am Eingang R, dem Rücksetzein- 
gang, auf '1'. Wir erwarten, dass das Flipflop zurückgesetzt wird. In Form von 
Ereignissen passiert dies wie folgt: Die Änderung am Eingang R ist ein Ereignis, 
welches in der Warteschlange gespeichert wird. Dieses Ereignis wird sofort verar- 
beitet, denn es ist das einzige Ereignis in der Warteschlange. Dieses Ereignis weckt 
gate2, da dieses sensitiv ist bezüglich Änderungen an seinem Eingang b. gate2 
wird daraufhin die nor-Funktion berechnen (mit einem Ergebnis von 'Q') und wird 
sodann die Zuweisung c <='Q' ausführen. Diese Schreibweise bezeichnet eine so- 
genannte Signalzuweisung. Dies bedeutet, dass die neuen Werte zunächst nur in der 
Warteschlange gespeichert werden. Die tatsächliche Zuweisung zur Variablen auf 
der linken Seite erfolgt erst, wenn der Zeitpunkt zur Bearbeitung dieses Eintrags in 
der Warteschlange erreicht ist. In unserem Beispiel wird ein Ereignis erzeugt, wel- 
ches verlangt, dass Ausgang c von gate2 auf '0' gesetzt wird und dieses Ereignis 
wird in der Warteschlange gespeichert. 

Dieses Ereignis wird sofort aus der Warteschlange geholt, da es das einzige 
Ereignis ist. Das Ereignis wird Ausgang c auf '@' setzen. Diese Änderung wird 
gatel wecken, da gate1 darauf sensitiv ist. gate1 wird folglich ebenfalls die nor - 
Funktion berechnen. Diese Berechnung führt zu einem Ereignis, als dessen Wirkung 
Ausgang c von gatel auf '1' zu setzen ist. Dieses Ereignis wird ebenfalls in der 
Warteschlange gespeichert. 

Dieses Ereignis wird ebenfalls sofort verarbeitet und es führt zum gewünschten 
Setzen des Werts am Ausgang. Diese Änderung wird gate2 erneut wecken. gate2 
berechnet wieder den Wert '0' am Ausgang. Der weitere Verlauf wird etwas davon 
abhängen, auf welche Weise man erkennt, dass sich ein stabiler Zustand eingestellt 
hat und dass keine weiteren Ereignisse zu erzeugen sind. 

Im Beispiel hätten wir echte Verzögerungen um physikalische Zeiten hinzufügen 
können und so eine Übersicht über die verstrichene Zeit gehabt. Insgesamt approxi- 
miert diese ereignisbasierte Simulation das Verhalten eines echten Flipflops. Vv 


2.7.2 Mehrwertige Logik 


Welche Werte sollten wir fiir die Simulation im obigen Beispiel benutzen? In diesem 
Buch beschränken wir uns auf die Beschreibung von eingebetteten Systemen, die mit 
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binärer Logik implementiert werden. Trotzdem ist es ratsam oder sogar notwendig, 
mehr als zwei Signalwerte zur Modellierung solcher Systeme zu verwenden. Bei- 
spielsweise könnte ein System elektrische Signale unterschiedlicher Stärke enthalten, 
und die Stärke und der Wert des Signals, das entsteht, wenn man mehrere solcher 
Signale zusammenschaltet, müssen berechnet werden. Im Folgenden werden wir 
deshalb zwischen dem Wert und der Stärke eines Signals unterscheiden. Während 
Ersteres eine Abstraktion der Signalspannung darstellt, ist Letzteres eine Abstrakti- 
on der Impedanz (des Innenwiderstands) der Spannungsquelle. Wir werden diskrete 
Wertemengen verwenden, um die Signalwerte und Signalstärken zu beschreiben. 
Unbekannte elektrische Signale werden durch spezielle Signalwerte modelliert. 

In der Praxis verwenden elektronische Entwurfssysteme eine Vielzahl von Wer- 
temengen. Einige Systeme erlauben nur zwei Werte, andere 9 oder sogar 46. Das 
Ziel bei der Entwicklung solcher diskreter Wertemengen ist es, das Lösen von Netz- 
werkgleichungen (z.B. nach Kirchhoff) zu vermeiden, aber existierende Systeme 
trotzdem ausreichend genau zu modellieren. 

Im Folgenden zeigen wir einen Weg, wie man systematisch zu Wertemengen 
kommt und diese zueinander in Relation setzt. Wir werden die Stärke der elek- 
trischen Signale als Hauptunterscheidungsmerkmal für verschiedene Wertemengen 
verwenden. Eine systematische Methode, wie man solche Wertemengen aufbau- 
en kann, die CSA-Theorie, wurde von Hayes vorgestellt [209]. Später werden wir 
zeigen, wie die normalerweise von VHDL-Modellen verwendete Wertemenge als 
Spezialfall erzeugt werden kann. 


Eine Signalstärke (Zwei Logikwerte) 


Im einfachsten Fall werden lediglich zwei Logikwerte verwendet. Sie heißen '®' und 
'1'. Diese Werte werden als gleich stark angenommen. Das bedeutet, wenn zwei 
Kabel miteinander verbunden werden, von denen eines den Wert '®', das andere 
den Wert '1' hat, so kann man den Wert des entstehenden Signals nicht bestimmen. 

Eine einzige Signalstärke kann ausreichend sein, um ein System zu modellieren, 
bei dem nie zwei Signale mit unterschiedlichen Werten verbunden werden und in 
dem sich keine Signale mit unterschiedlichen Stärken in einer bestimmten Hardware- 
Einheit treffen. 


Zwei Signalstärken (Drei und Vier Logikwerte) 


In vielen Schaltungen gibt es den Fall, dass ein elektrisches Signal nicht aktiv von 
einem Ausgang getrieben wird. Dies kann vorkommen, wenn eine Leitung weder mit 
Masse noch mit der Versorgungsspannung oder einem anderen Knoten der Schaltung 
verbunden ist. 
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Beispielsweise können Systeme sogenannte Open-Collector-Ausgänge haben 
(siehe Abb. 2.58 (links))!°). Der Ausgang A ist effektiv abgeschaltet, wenn der Pull- 
Down-Transistor PD nicht leitet. Bei Tristate-Ausgängen (siehe Abb. 2.58 (rechts)) 


VDD — VDD 
Ag 
input A enable— A 
—[ PD 7—1 H PD 
Masse Masse : 
Input='9' — A unverbunden enable='%' — A unverbunden 


Abb. 2.58 Abschaltbare Ausgänge: links: Open-Collector-Ausgang; rechts: Tristate-Ausgang 


wird ein Wert '@' des enable-Signals eine '@' an den Ausgängen der UND-Gatter 
(mit & gekennzeichnet) erzeugen und beide Transistoren nichtleitend machen!’. Da- 
mit können wir mit geeigneten Eingangssignalen Ausgänge effektiv vom Rest der 
Schaltung trennen. 

Offensichtlich ist die Signalstärke eines solchen unverbundenen Ausgangs die 
kleinste Signalstärke, die man sich vorstellen kann. Insbesondere ist diese Signal- 
stärke kleiner als die von 'Q' und '1'. Außerdem ist der Signalwert eines solchen 
Signals unbekannt. Diese Kombination von Signalstärke und Signalwert wird durch 
den Logikwert mit dem Namen 'Z' dargestellt. Wenn ein Signalwert 'Z' mit ir- 
gendeinem anderen Signal zusammengeschaltet wird, dominiert immer das andere 
Signal. Wenn also beispielsweise zwei Tristate-Ausgänge an denselben Bus ange- 
schlossen sind und einer der Ausgänge steuert ein 'Z' bei, so ist der Ergebniswert 
auf dem Bus immer der Wert des zweiten Ausgangs (siehe Abb. 2.59). 


VDD 
fe al—s 
bus 


enable='e' 7 — enable='1' 
_ & & _ 
PD PD' — E 


Masse 


Abb. 2.59 Der rechte Ausgang dominiert den Bus 


Was passiert, wenn die beiden Ausgänge in Abb. 2.59 versuchen, starke Signale 
mit unterschiedlichen Werten beizusteuern? Zur Behandlung solcher Situationen 


16 Schaltpläne sollen den Studenten helfen, die Signalwerte zu verstehen und es nicht schwieriger 
machen. Studierende, denen Schaltpläne fremd sind, können einfach die Logikwerte betrachten. 

17 In der Praxis können Pull-Up-Transistoren Verarmungstransistoren sein und die Tristate- 
Ausgänge können invertierend sein. 
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werden dreiwertige Logikmengen {'@', '1', 'Z'} in der Regel durch einen vierten 
Wert mit dem Namen 'X' ergänzt. 'X' beschreibt den unbekannten Signalwert 
der gleichen Stärke wie '®' und '1'. Genauer ausgedrückt wird der Wert 'X' 
verwendet, um unbekannte Signale darzustellen, die entweder einen der Werte 'Q' 
oder '1' haben oder aber eine Spannung darstellen, die keinem dieser beiden Werte 
entspricht!®. 

Wenn mehrere Signale verbunden werden, dann miissen wir den resultierenden 
Signalwert berechnen. Dies kann man tun, indem man die partielle Ordnung der 
vier Signalwerte '@', '1', 'Z' und ’X’ gemäß ihrer Signalstärke ausnutzt. Diese 
partielle Ordnung ist im Hasse-Diagramm in Abb. 2.60 dargestellt: Die Kanten in 


Xx! 
Abb. 2.60 Partielle Ordnung der Wertemenge 2 
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der Abbildung zeigen die Dominanz von Signalwerten. Die Kanten definieren eine 
Relation > auf den Elementen. Wenn a > b, dann dominiert a das Signal b (oder b 
wird von a dominiert). '@' und '1' dominieren 'Z' , wohingegen 'X' alle anderen 
Signalwerte dominiert. Ausgehend von der Relation > definieren wir eine Relation 
>. Die Aussage a > b gilt genau dann, wenn a > b oder wenn a = b. 

Wir definieren weiter eine Operation sup auf zwei Signalen, die das Supremum 
der beiden Signalwerte zurückliefert. 


Definition 2.23: Seien a und b zwei Signalwerte einer partiell geordneten Menge 
(S, >). Das Supremum c € S ist das schwächste Signal, für das c > a und c > b 
gilt. 

So ist z.B. sup ('Z' ,'0')='0', sup('Z' ,'1')='1', sup ('0','1')='X' usw. 


Lemma 2.1: Seien a und b zwei Signale einer partiell geordneten Menge, wobei die 
partiell geordnete Menge wie oben gewählt sei. Dann berechnet die sup-Funktion 
den Signalwert, der sich ergibt, wenn man die beiden Signale miteinander verbindet. 


Sup entspricht dem connect-Element der CSA-Theorie. 


Drei Signalstärken (Sieben Signalwerte) 


Für viele Schaltungen sind zwei Signalstärken nicht ausreichend. Ein häufig vor- 
kommender Fall, der mehr Werte benötigt, ist die Verwendung von sogenannten 
Verarmungstransistoren (engl. depletion transistors, siehe Abb. 2.61). 


18 Es gibt auch andere Interpretationen von 'x' [65], aber die oben genannte Interpretation ist für 
unsere Zwecke am Besten geeignet. 
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Abb. 2.61 Ausgang mit Verarmungstransistoren 
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Der Effekt von Verarmungstransistoren ist vergleichbar mit der Verwendung ei- 
nes Widerstands, der eine hochohmige Verbindung zur Versorgungsspannung VDD 
herstellt. Verarmungstransistoren dienen genau wie der Pull-Down-Transistor PD als 
Signaltreiber für den Knoten A der Schaltung und der Signalwert am Knoten A kann 
mit Hilfe einer Supremumsbildung berechnet werden. Der Pull-Down-Transistor lie- 
fert einen Treiberwert von '®' oder 'Z' , je nachdem, wie der Eingabewert von PD 
ist. Der Verarmungstransistor liefert ein Signal, das schwächer ist als '®' und '1'. 
Der Signalwert entspricht jedoch einem Wert von '1'. Wir bezeichnen den Signal- 
wert, den der Verarmungstransistor liefert, mit 'H' und wir nennen ihn „schwache 
logische Eins“. Analog kann es auch „schwache logische Nullen“ geben, die durch 
'L' gekennzeichnet werden. Der Wert, der entsteht, wenn man eine Verbindung 
zwischen 'H' und 'L' herstellt, heißt „schwach logisch undefiniert“, geschrieben 
als 'W' . Daraus ergeben sich drei Signalstärken und die sieben Signalwerte {'®', 
'1', 'Z', 'X', "H', 'L', 'W'}. Die Berechnung des resultierenden Wertes basiert 
wieder auf der partiellen Ordnung aus diesen sieben Signalwerten, die in Abb. 2.62 
gezeigt wird. Diese Ordnung definiert wieder eine Operation sup, die das schwächste 


+ X t 
Abb. 2.62 Partielle Ordnung für die Wertemenge g \ 
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Signal zurückliefert, das mindestens so stark ist wie eines der beiden Argumente. 
Beispielsweise gilt sup('H', '0')='', sup('H', 'Z')='H', supC'H', 'L')= 'W'. 

'Q' und 'L' kennzeichnen den gleichen Signalwert, aber mit unterschiedlicher 
Signalstärke. Das gleiche gilt für '1' und 'H'. Geräte, welche die Stärke eines Signals 
erhöhen, heißen Verstärker. Geräte, welche die Stärke eines Signals erniedrigen, 
heißen Abschwächer (engl. attenuator). 
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Vier Signalstärken (Zehn Signalwerte) 


In einigen Fällen sind auch drei Signalstärken nicht ausreichend. Beispielsweise gibt 
es Schaltungen, die Verbindungsleitungen als Ladungsspeicher verwenden. Solche 
Leitungen werden während einer bestimmten Betriebsphase mit den Logikwerten 
'@' oder '1' vorgeladen. Diese Ladungen können den (hochohmigen) Eingang 
einiger Transistoren steuern. Werden diese Leitungen mit einer Signalquelle (außer 
einer mit dem Wert ’Z’) verbunden, so verlieren sie ihre Ladung und das Signal der 
zweiten Quelle dominiert. 


Beispiel 2.28: In Abb. 2.63 wird beispielsweise ein Bus von einem speziellen Aus- 
gang getrieben. Angenommen, der Bus stellt eine hoch-kapazitive Belastung dar, 


VDD ¥— 
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Masse 


Abb. 2.63 Vorladen eines Busses 


äquivalent zu einem Kondensator C mit hoher Kapazität. Mit dieser gehen wir wie 
folgt um: Während die Funktion f noch den Wert '®' liefert, wird d auf den Wert 
'1' gesetzt, wodurch der Kondensator C aufgeladen wird. Danach wird ¢ auf '0' 
gesetzt. Wenn der Wert von f bekannt wird und wenn er gleich '1' ist, wird der Bus 
entladen. V 


Dieses sogenannte Vorladen oder Precharging wird verwendet, da das Aufladen 
eines Busses hoher Kapazität mit einem Ausgang wie dem in Abb. 2.61 gezeigten ein 
langsamer Prozess ist, weil der Widerstand des Verarmungstransistors relativ groß 
ist. Die Entladung durch normale „Pull-Down-Transistoren“ PD erfolgt dagegen 
schneller. 

Um solche Fälle modellieren zu können, brauchen wir Signalwerte, die schwächer 
sind als 'H' und 'L' , aber stärker als 'Z' . Wir nennen solche Werte „sehr schwa- 
che Signalwerte“ und schreiben sie als 'h' und 'l' . Der zugehörige sehr schwache 
undefinierte Signalwert heißt 'w' . Damit erhalten wir zehn Signalwerte {'0', '1', 
'L','H', TU, 'h', 'X', 'W', 'w', 'Z'}. Mit Hilfe der Signalstärken kann wieder 
eine partielle Ordnung auf diesen Werten definiert werden (siehe Abb. 2.64). Prech- 
arging ist durchaus risikobehaftet: nachdem ein vorgeladener Bus einmal entladen 
ist, z.B. durch ein transientes Signal, kann er in derselben Taktperiode nicht wieder 
aufgeladen werden. 
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Bislang haben wir die Versorgungsspannungen nicht betrachtet. Diese sind stärker 
als alle bisher betrachteten Signale. Signalwertemengen, welche die Versorgungs- 
spannungen beinhalten, haben zur Definition einer 46-elementigen Signalwertmenge 
geführt, die auch Signalflanken erfasst [106]. Solche Modelle sind allerdings nicht 
sehr weit verbreitet. 


2.7.3 Transaktionsbasierte Modellierung 


Simulation auf der Basis diskreter Ereignissysteme erlaubt es uns, Zeitverhalten zu 
simulieren. Allerdings stellt sich die Frage, wie genau wir die Zeit modellieren kön- 
nen. Ein sehr genaues Modell, welches das Zeitverhalten der Signal präzise erfasst, 
wird lange Simulationszeiten verursachen. Insbesondere benötigen wir sehr lange 
Simulationszeiten, wenn wir elektrische Schaltkreise simulieren wollen. Kürzere Si- 
mulationszeiten sind möglich, wenn wir zyklengenaue Simulationen verwenden, bei 
denen wir synchrone (getaktete) Schaltungen taktgenau simulieren. Noch kürzere 
Simulationszeiten sind möglich, wenn wir noch gröbere Zeitmodelle verwenden. In 
diesem Zusammenhang hat die sogenannte transaktionsbasierte Modellierung (engl. 
Transaction-Level Modeling (TLM)) eine große Beachtung gefunden. TLM kann 
wie folgt definiert werden: 


Definition 2.24 (Grötker et al. [191]): ,,Transaktionsbasierte Modellierung ist 
ein Ansatz zur Modellierung digitaler Systeme auf hoher Ebene, bei dem die De- 
tails der Kommunikation zwischen den Modulen von den Details der Implementie- 
rung der funktionellen Einheiten und der Kommunikationsarchitektur getrennt sind. 
Kommunikationsmechanismen wie Busse oder FIFOs werden als Kanäle modelliert 
und werden den Modulen als SystemC-Schnittstellenklassen angeboten. Transak- 
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tionsanforderungen ergeben sich aus Aufrufen der Schnittstellenfunktionen dieser 
Kanalmodelle, welche die Details des Informationsaustausches kapseln. Auf der 
Transaktionsebene liegt die Betonung mehr auf der Funktionalität des Datentrans- 
fers — welche Daten werden woher und wohin transportiert — und weniger bei der 
tatsächlichen Implementierung, d.h. beim tatsächlich für den Transfer benutzten 
Protokoll. Dieser Ansatz macht es für den Systemdesigner einfacher, beispielsweise 
mit verschiedenen Busarchitekturen, die alle gemeinsame Schnittstellen haben, zu 
experimentieren, ohne dabei die Modelle abzuändern, die mit diesen Bussen inter- 
agieren. Dabei ist vorausgesetzt, dass diese Modelle mit dem Bus (nur) über die 
gemeinsamen Schnittstellen kommunizieren.” 


Eine detaillierte Unterscheidung zwischen verschiedenen Zeitmodellen wurde 
von Cai and Gajski [83] beschrieben. Sie unterscheiden zwischen Zeitmodellen für 
die Kommunikation und für Berechnungen!?. Cai and Gajski betrachten verschie- 
dene Fälle von Zeitmodellen, abhängig davon, wie präzise Kommunikation und 
Berechnungen modelliert werden. 

Sowohl für Berechnungen wie auch für die Kommunikation differenzieren wir 
zwischen keiner Zeitmodellierung, näherungsweiser Zeitmodellierung und zyklen- 
genauer Zeitmodellierung. In der Abb. 2.65 markieren Kreuze unausgewogene Kom- 
binationen von Zeitmodellen, die von Cai and Gajski nicht betrachtet wurden. Damit 
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Abb. 2.65 Unterschiede zwischen verschiedenen Zeitmodellen 


verbleiben noch sechs mögliche Fälle [83]: 


A Keine Zeitmodellierung: wir betrachten nur die Funktionalität und betrach- 
ten überhaupt keine Zeiten. Solche Modelle sind für frühe Entwurfsphasen 
angebracht. Man kann sie Spezifikationsmodell nennen. 

B Wir können im Spezifikationsmodell reine Verhaltensbeschreibungen durch 
Beschreibungen von Komponenten mit einem groben Zeitmodell ersetzen. 


19 Dies entspricht derselben Unterscheidung, die wir in Tabelle 2.1 auf Seite 44 vorgenommen 
haben. 
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Beispielsweise könnten wir die größtmögliche Laufzeit für die Ausführung 
von Code auf einem Prozessor kennen. Die Kommunikation würden wir 
immer noch abstrakt modellieren. Als Ergebnis würden wir den Knoten B 
in Abb. 2.65 erhalten. Man kann ein solches Modell component-assembly 
model nennen. 

C In einem Modell vom Typ B könnten wir abstrakte Kommunikation durch 
Kommunikation mit einem näherungsweisen Zeitmodell ersetzen. Dies be- 
deutet, dass wir Zugriffskonflikte und ihren Einfluss auf das Zeitverhalten 
modellieren, aber wir modellieren nicht jedes Signal und wir beziehen uns 
nicht auf Taktzyklen. Ein solches Modell kann bus-arbitration model genannt 
werden. 

D In einem Modell vom Typ C könnten wir näherungsweise Zeitinformation 
für die Kommunikation durch taktgenaue Zeitinformation ersetzen. Damit 
würden wir in der Simulation eine Übersicht über benötigte Taktzyklen be- 
kommen. Wir könnten ggf. sogar die echte, physikalische Zeit verwenden. 
Das resultierende Modell, in Abb. 2.65 als Knoten D bezeichnet, können wir 
bus-functional model [83] nennen. 

E In einem Modell vom Typ C können wir näherungsweise Zeitmodelle für 
Berechnungen durch ein taktgenaues Modell der Berechnungen ersetzen. Da- 
mit können wir z.B. Speicherreferenzen im Detail erfassen. Das resultierende 
Modell können wir zyklengenaues Berechnungsmodell nennen. 

F Der mit F bezeichnete Knoten wird erhalten, wenn Kommunikation und 
Berechnungen zyklengenaue Zeiten verwenden. Wir können das Modell Im- 
plementierungsmodell nennen. 


Entwurfsprozeduren müssen das Diagramm in Abb. 2.65 vom Knoten A zum 
Knoten F durchlaufen. 


2.7.4 SpecC 


Die SpecC-Sprache [173] zeigt sehr schön, wie eine Unterscheidung zwischen Kom- 
munikation und Berechnung aussehen kann und sie zeigt die TLM-Prinzipien. SpecC 
modelliert Systeme als hierarchische Netzwerke von in ihrem Verhalten beschriebe- 
nen Komponenten, die über Kanäle kommunizieren. SpecC-Beschreibungen beste- 
hen aus Verhalten (behaviors), Kanälen (channels) und Schnittstellen (interfaces). 
Verhalten enthält Ports, lokal instantiierte Komponenten, private Variablen und 
Funktionen sowie eine nach außen sichtbare main-Funktion. Kanäle kapseln die 
Kommunikation. Sie enthalten Variablen und Funktionen, die zur Definition von 
Kommunikationsprotokollen verwendet werden. Schnittstellen verbinden Verhalten 
und Kanäle. Sie deklarieren die Kommunikationsprotokolle, die innerhalb eines 
Kanals definiert werden. SpecC kann Hierarchien mit Hilfe von geschachteltem 
Verhalten modellieren. 
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Beispiel 2.29: Abb. 2.66 [173] zeigt eine Komponente G, die Unterkomponenten g1 
und g2 enthält. 


Abb. 2.66 Strukturelle a je —ı R}— p2 
Hierarchie in SpecC 


Die strukturelle Hierarchie wird in dem folgenden SpecC-Modell beschrieben: 


01: interface L { void Write(int x); }; 
02: interface R { int Read(void); }; 
03: channel H implements L,R { 
04: int Data; bool Valid; 
05: void Write(int x) { Data=x; Valid=true; } 
06: int Read(void) { 
07: while (!Valid) waitfor (10); 
08: return (Data); 
09: } 
ec; 
behavior Gi(in int pl, L p2, out int p3) { 
void main (void) { /*...*/ p2.Write(pl); } }; 
behavior G2(in int pl, R p2, out int p3) { 
void main(void) { /*...*/ p3=p2.Read(); } }; 
behavior G(in int p1, out int p2) { 
int h]; H h2; G1 g1(p1, h2, h1); G2 g2(h1, h2, p2); 
void main (void) { 
par { gl.main(); g2.main(); } 
} 
}; 
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Die parallele Ausführung der Teilkomponenten wird durch das Schlüsselwort par 
in Zeile 18 ausgedrückt. In Zeile 16 ist zu sehen, dass Teilkomponenten über die 
Ganzzahl h1 und durch den Kanal h2 kommunizieren. Das im Kanal H implemen- 
tierte Schnittstellenprotokoll, das aus Lese- und Schreiboperationen besteht (siehe 
Zeilen 05 und 06) kann geändert werden, ohne die Verhalten G1 and G2 zu ändern. 
Beispielsweise kann die Kommunikation bitseriell oder parallel sein und die Wahl 
ändert nicht die Modelle von G1 und G2. Dieses Merkmal ist für die Wiederver- 
wendung von Hardwarekomponenten und geistigem Eigentum (engl. Intellectual 
Property (IP)) unverzichtbar. Das vorgestellte SpecC-Modell enthält keine Zeitin- 
formation. Es ist daher ein Spezifikationsmodell (Modelltyp A in Abb. 2.65). V 


Der Entwurfsablauf für SpecC wurde bereits in Abb. 1.9 auf Seite 25 gezeigt. Der 
Weg in der Abbildung 2.65 ist A, B, D, F [83]. Auf Spezifikationsebene kann SpecC 
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jede Form der Kommunikation verwenden. Ublicherweise wird der Nachrichtenaus- 
tausch benutzt. Das Kommunikationsmodell in SpecC hat das Kommunikationsmo- 
dell in SystemC 2.0 beeinflusst. 

SpecC basiert auf C++-Syntax. Diese Wahl wurde aus dem folgenden Grund ge- 
troffen: Es gibt den Trend, mehr und mehr Funktionalität in Software zu realisieren 
und dafiir die Sprache C zu benutzen. Beispielsweise implementieren eingebette- 
te Systeme Standards wie MPEG 1/2/4 oder Dekoder fiir Mobilfunkstandards wie 
GSM, UMTS oder LTE. Diese Standards sind haufig in Form von ,,Referenzimple- 
mentierungen” verfügbar, die aus C-Programmen bestehen, die nicht auf Effizienz 
optimiert sind, sondern die v.a. die notwendige Funktionalität bereit stellen. Der 
Nachteil von Entwurfsmethodiken, die auf speziellen HDLs (wie VHDL oder Ve- 
rilog, siehe unten) basieren, ist, dass die Standards in der jeweiligen HDL neu 
geschrieben werden müssen. Außerdem verlangt die gemeinsame Simulation von 
Hardware und Software das Verbinden von Hardware- und Softwaresimulatoren. 
Üblicherweise führt dies zu einem Verlust an Simulationseffizienz und inkonsisten- 
ten Benutzerschnittstellen. Auch müssten die Designer mehrere Sprachen lernen. 

Daher gab es das Bemühen, Hardwarestrukturen in Softwaresprachen zu model- 
lieren. Dazu mussten einige fundamentale Probleme gelöst werden: 


e Die in der Hardware übliche Nebenläufigkeit (engl. concurrency) muss in Soft- 
ware modelliert werden. 

« Es gibt die Notwendigkeit, die Zeit darzustellen. 

e Mehrwertige Logik, wie oben beschrieben, sollte benutzt werden können. 

e Das deterministische Verhalten fast aller sinnvollen Hardwareschaltungen sollte 
sichergestellt sein. 


Für die SpecC-Sprache wie auch für andere HDLs wurden diese Probleme gelöst. 


2.7.5 SystemC 


TLM-Modellierung und die Trennung zwischen Kommunikation und Berechnung 
sind auch in der Sprache SystemC’ verfügbar. SystemC basiert wie SpecC auf C 
und C++. Zur abstrakten Modellierung der Kommunikation bietet SystemC Kanäle, 
Ports und Schnittstellen, ähnlich wie SpecC. Damit wird die TLM-Modellierung 
erleichtert. 

SystemC” [521, 244] ist eine C++-Klassenbibliothek. Bei Verwendung von Sys- 
temC können Spezifikationen in C oder in C++ geschrieben werden, wobei an den 
entsprechenden Stellen Referenzen auf die Klassenbibliothek eingesetzt werden. 

SystemC beinhaltet die gleichzeitige Ausführung mehrerer Prozesse. Die Ausfüh- 
rung von Prozessen wird über Sensitivitätslisten und Aufrufe von wait -Instruktionen 
gesteuert. Sensitivitätslisten können dynamisch sein, d.h. die Liste der Signale, auf 
deren Änderungen reagiert wird, kann sich während der Ausführung verändern. 

SystemC hat auch ein Modell für die Zeit. SystemC 1.0 verwendet Gleitkomma- 
zahlen, um die Zeit darzustellen. In SystemC 2.0 wird eine ganzzahlige Darstellung 
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bevorzugt. SystemC 2.0 unterstützt auch physikalische Einheiten wie Pikosekunden, 
Nanosekunden, Mikrosekunden usw. 

Die Datentypen von SystemC beinhalten alle üblichen Hardware-Typen: vier- 
wertige Logik ('@', '1', 'X' und 'Z') sowie Bitvektoren unterschiedlicher Länge 
werden unterstiitzt. Die Beschreibung von Anwendungen aus der digitalen Signalver- 
arbeitung wird durch die Verfiigbarkeit von Typen fiir Festkommazahlen vereinfacht. 

Deterministisches Verhalten (siehe Seite 66) wird im Allgemeinen nicht garan- 
tiert, sondern nur durch Verwendung eines bestimmten Modellierungsstils erreicht. 
Mit Hilfe eines Kommandozeilenschalters kann der Simulator angewiesen werden, 
Prozesse in unterschiedlichen Reihenfolgen auszuführen. So kann der Benutzer über- 
prüfen, ob die Simulationsergebnisse von der Reihenfolge der Prozessausführungen 
abhängen. Für Modelle mit realistischer Komplexität kann man allerdings nicht 
nachweisen, ob sie deterministisch sind — man kann nur zeigen, dass ein Modell 
nichtdeterministisch ist. 

Montoreano beschreibt die TLM-Modellierung mit SystemC [402]. Er unter- 
scheidet zwischen nur zwei Typen von TLM-Modellen: 


e Schwach zeitbehaftete Modelle: sie werden wie folgt beschrieben [402]: „Diese 
Modelle besitzen eine geringe Abhängigkeit zwischen Daten und Zeitinformation, 
und sie können die gewünschten Daten und Zeitinformation bereitstellen, wenn 
Transaktionen gestartet werden. Die Erzeugung einer Antwort (z.B. auf eine 
Leseanforderung) setzt nicht voraus, dass die (Simulations-)zeit fortschreitet. 
Der Wettbewerb um Ressourcen und deren Verteilung werden in diesen Modellen 
üblicherweise nicht erfasst. Aufgrund der geringen Abhängigkeit und minimalen 
Umschalten des Kontextes können diese Modelle die schnellsten sein und sie sind 
besonders bei der Softwareentwicklung auf einer virtuellen Plattform nützlich.” 

e Modelle mit approximierten Zeiten: sie werden wie folgt beschrieben [402]: 
„Bei diesen Modellen kann die Bereitstellung einer Antwort von dem Feuern 
interner oder externer Ereignisse und/oder auch der fortschreitenden Zeit abhän- 
gen. Wettbewerb um Ressourcen und deren Zuordnung können mit diesem Stil 
leicht modelliert werden. Diese Modelle benötigen mehrere Kontextwechsel in 
der Simulation, um die verschiedenen Transaktionen vor ihrer Ausführung zu 
synchronisieren oder zu ordnen, was zu einem Verlust an Simulationsgeschwin- 
digkeit führt.” 


Für den praktischen Entwurf ist es wichtig, aus den Modellen heraus mit Syn- 
theseverfahren eine Implementierung in Hard- oder Software erzeugen zu können. 
Die Synthese von Hardware aus SystemC-Modellen ist verfügbar [216, 217]. Es 
gibt auch kommerzielle Werkzeuge zur Synthese aus SystemC heraus. Eine syn- 
thetisierbare Untermenge der Sprache ist definiert worden [8]. Für kommerzielle 
Werkzeuge wird erwartet, dass sie mindestens aus der synthetisierbaren Untermen- 
ge eine Implementierung erzeugen können. In einem Buch werden Methodik und 
Anwendungen SystemC-basierten Entwurfs vorgestellt [408]. Gegenwärtig (im Jahr 
2020) ist SystemC 2.3.1 die jüngste Version von SystemC [7]. 
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2.7.6 VHDL 


Einführung 


VHDL ist eine weitere Sprache, die auf der Modellierung mittels diskreter Ereignisse 
basiert. Im Gegensatz zu SpecC und SystemC unterstützt sie keine klare Unterschei- 
dung zwischen Kommunikation und Berechnung, was die Wiederverwendung von 
Komponenten erschwert. Allerdings wird VHDL durch viele kommerzielle und aka- 
demische Werkzeuge unterstützt und ist weit verbreitet. Es ist ein (weiteres) Beispiel 
einer Hardwarebeschreibungssprache. Nachdem wir ein erstes Beispiel ereignisba- 
sierter Modelle bereits auf Seite 97 vorgestellt haben, wollen wir uns jetzt näher mit 
VHDL beschäftigen. 

VHDL verwendet Prozesse, um parallele Ausführung zu beschreiben. Jeder 
VHDL-Prozess modelliert eine Komponente einer möglicherweise nebenläufigen 
Hardware. Für einfache Komponenten kann ein einzelner VHDL-Prozess ausrei- 
chend sein. Um komplexere Hardwarekomponenten zu modellieren, benötigt man in 
der Regel mehrere Prozesse. VHDL-Prozesse kommunizieren über Signale mitein- 
ander. Signale entsprechen in etwa den physischen Verbindungen in der Hardware, 
also z.B. Leitungen oder Drähten. 

Die Ursprünge von VHDL reichen bis in die achtziger Jahre des letzten Jahrhun- 
derts zurück. Bis dahin wurden die meisten Systeme mit Hilfe graphischer HDLs 
beschrieben. Der meistverwendete Baustein einer solchen Darstellung war ein einzel- 
nes Gatter. Zusätzlich zu einer graphischen Darstellung kann man auch eine textuelle 
HDL-Beschreibung erstellen. Die Stärke von textuellen Darstellungen liegt in der 
Möglichkeit, relativ leicht komplexe Berechnungen mit Variablen, Schleifen, Funk- 
tionsparametern und Rekursionen darstellen zu können. Folglich wurden graphische 
Darstellungen fast vollständig von textuellen HDL s ersetzt, als die digitalen Systeme 
immer komplexer wurden. Die textuellen HDL-Darstellungen waren ursprünglich 
ein Forschungsthema an Universitäten. Mermet et al. [393] geben einen Überblick 
über die in Europa im Laufe der achtziger Jahre entwickelten Sprachen. MIMOLA 
war eine dieser Sprachen und der Autor dieses Buches hat zu ihrem Entwurf und 
ihrer Anwendung beigetragen [380, 374]. Textuelle Sprachen wurden beliebt, als 
VHDL und der Konkurrent Verilog (siehe Seite 120) eingeführt wurden. 

VHDL wurde im Rahmen des VHSIC-Programms des US-amerikanischen Ver- 
teidigungsministeriums entwickelt. VHSIC steht für Very High Speed Integrated Cir- 
cuits. Ursprünglich wurde der Entwurf von VHDL (VHSIC Hardware Description 
Language) von drei Firmen durchgeführt: IBM, Intermetrics und Texas Instruments. 
Eine erste Version von VHDL wurde 1984 veröffentlicht. Später wurde VHDL dann 
von der IEEE unter dem Namen IEEE 1076 standardisiert. Die erste IEEE-Version 
von VHDL wurde im Jahre 1987 verabschiedet und in den Jahren 1993, 2000, 2002 
und 2008 aktualisiert [238, 240, 241, 242, 243]. VHDL-AMS erlaubt zusätzlich die 
Modellierung analoger und gemischt analog/digitaler (engl. mixed-signal) Systeme 
durch die Erweiterung der Sprache um Differentialgleichungen [246]. Der Entwurf 
von VHDL nahm Ada (siehe Seite 123) als Ausgangspunkt, da beide Sprachen für 
das US-amerikanische Verteidigungsministerium entworfen wurden. Weil Ada auf 
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PASCAL basiert, hat VHDL einige syntaktische Eigenheiten von PASCAL über- 
nommen. Allerdings ist die Syntax von VHDL im Allgemeinen sehr viel komplexer, 
sodass man aufpassen muss, um sich nicht verwirren zu lassen. In diesem Buch 
werden nur einige Konzepte von VHDL vorgestellt, die auch in anderen Sprachen 
vorkommen oder aber nützlich sind. Eine vollständige Beschreibung des VHDL- 
Sprachstandards ist nicht Bestandteil dieses Buches. Ihn kann man von der IEEE 
erhalten [243]. 


Entities und Architectures 


Wie alle anderen HDLs auch, beinhaltet VHDL die fiir die Modellierung neben- 
läufiger Operationen benötigte Unterstützung. In VHDL heißen die modellierten 
Hardwarekomponenten Design Entity oder VHDL Entity. Innerhalb von Entities 
werden VHDL-Prozesse verwendet, um Nebenläufigkeit darzustellen. Die VHDL- 
Sprachbeschreibung definiert, dass Entities aus zwei Typen von Bestandteilen be- 
stehen: einer Entity-Deklaration und einer (oder mehrerer) Architekturen (engl. 
Architectures (siehe Abb. 2.67)). 


Entity-Deklaration 


BAER mS 


Architektur 1 Architektur 2 Architektur 3 en | 


Abb. 2.67 Entity bestehend aus einer Entity-Deklaration und Architekturen 


Für jede Entity wird im Standardfall die zuletzt analysierte Architektur verwendet. 
Es kann aber auch angegeben werden, dass eine andere Architektur verwendet werden 
soll. 


Beispiel 2.30: Als Beispiel betrachten wir einen Volladdierer. Volladdierer haben 
drei Eingänge und zwei Ausgänge (siehe Abb. 2.68). 


a > > sum 
b —> full_adder 
carry_in — carry_out 


Abb. 2.68 Ein Volladdierer und seine Schnittstellensignale 


Eine Entity-Deklaration, die Abb. 2.68 entspricht, könnte etwa wie folgt aussehen: 
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entity full_adder is -- Entity-Deklaration 
port (a, b, carry_in: in BIT; -- Eingänge 
sum, carry_out: out BIT); -- Ausgänge 


end full_adder; 


Kommentare werden durch einen doppelten Bindestrich (--) eingeleitet und en- 
den am Zeilenende. V 


Architekturen bestehen aus Architekturköpfen und Architekturrümpfen. Man 
kann verschiedene Stile von Rümpfen unterscheiden, nämlich strukturelle Rümpfe 
und Verhaltensrümpfe. Wir zeigen die Unterschiede zwischen diesen beiden Mo- 
dellierungsarten am Beispiel des Volladdierers. Verhaltensrümpfe enthalten nur die 
Informationen, die benötigt werden, um aus Eingabesignalen und internem Zustand 
(wenn es einen gibt) die Ausgabesignale und den neuen internen Zustand zu berech- 
nen. Dies beinhaltet auch das zeitliche Verhalten. 


Beispiel 2.31: Das folgende Beispiel zeigt einen Verhaltensrumpf: 


architecture behavior of full_adder is -- Architektur 
begin 
sum <= (a xor b) xor carry_in after 10 ns; 


carry_out <= (a and b) or (a and carry_in) or 
(b and carry_in) after 10 ns; 
end behavior; 


VHDL-basierte Simulatoren können die Ausgabesignale graphisch als Signalver- 
läufe darstellen. Diese ergeben sich, wenn Werte an die Eingabeports des Volladdie- 
rers gelegt werden. 

Im Gegensatz zu Verhaltensrümpfen beschreiben strukturelle Architekturrümpfe 
die Art und Weise, in der Entities aus einfacheren Entities zusammengebaut sind. 
Beispielsweise kann der Volladdierer als Entity modelliert werden, die aus drei 
Komponenten besteht (siehe Abb. 2.69). Diese Komponenten heißen i1 , i2 und i3 
und sind vom Typ half_adder oder or_gate . 


full_adder 
a = il: = HI > carry_out 
b ——y half_adder 


i2: 
half_adder 


Abb. 2.69 Schematische Darstellung des Strukturrumpfes des Volladdierers 


carry_in sum 


In der 1987er-Version von VHDL mussten diese Komponenten in einer sogenann- 
ten Component-Deklaration vorgestellt werden. Diese Deklaration ist der Forward- 
Deklaration anderer Programmiersprachen sehr ähnlich und dient auch genau dem 
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gleichen Ziel: sie stellt genügend Informationen über eine Komponente zur Verfü- 
gung, die zu dem Zeitpunkt evtl. noch nicht in der VHDL-Datenbank gespeichert ist 
(was bei sogenannten Top-Down-Designs vorkommen kann). Ab der 1993er-Version 
von VHDL sind solche Deklarationen nicht mehr notwendig, wenn die benötigten 
Komponenten bereits in der Komponentendatenbank abgelegt wurden. 

Verbindungen zwischen lokalen Komponenten und den Ports der Entity werden 
mit Hilfe von Port Maps beschrieben. Der folgende VHDL-Code beschreibt den 
Strukturrumpf aus Abb. 2.69: 


architecture structure of full_adder is -- Architektur-Kopf 
component half_adder 
port (inl, in2: in BIT; carry: out BIT; sum: out BIT); 
end component; 
component or_gate 
port (inl, in2: in BIT; o: out BIT); 
end component; 


signal x, y, z: BIT; -- lokale Signale 

begin -- port map 

il: half_adder -- Instanz il vom Typ half_adder 

port map (a, b, x, y); -- Verbindungen zwischen Ports 

i2: half_adder port map (y, carry_in, z, sum); -- Instanz i2 
i3: or_gate port map (x, z, carry_out); 


end structure; 


Zuweisungen 


Beispiel 2.31 enthält mehrere Zuweisungen. Zuweisungen sind Spezialfälle von 
Anweisungen. In VHDL gibt es zwei verschiedene Arten von Zuweisungen: 


e Variablenzuweisungen: Die Syntax für Variablenzuweisungen lautet 
Variable := Ausdruck 


Wenn der Kontrollfluss eine solche Zuweisung erreicht, wird der entsprechende 
Ausdruck berechnet und der Variablen zugewiesen. Diese Zuweisungen verhalten 
sich wie Zuweisungen in normalen Programmiersprachen. 

e Signalzuweisungen: Signalzuweisungen, die bereits auf den Seiten 97 und 111 
erwähnt wurden, werden nebenläufig ausgeführt. Signale und Signalzuweisungen 
wurden eingeführt, um elektrische Signale realer Hardwaresysteme modellieren 
zu können. Signale ordnen Werte bestimmten Zeitpunkten zu. Diese Abbildung 
wird in VHDL durch Signalverläufe dargestellt, die aus Signalzuweisungen be- 
rechnet werden. Die Syntax für Signalzuweisungen lautet 


signal <= expression; 

signal <= transport expression after delay; 

signal <= expression after delay; 

signal <= reject time inertial expression after delay; 
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Wenn der Kontrollfluss eine solche Zuweisung erreicht, wird der Ausdruck be- 
rechnet und dazu verwendet, zukiinftige Werte des Signalverlaufes vorauszusa- 
gen. In VHDL wird Signalen ein sogenannter Signaltreiber zugeordnet. Wenn es 
mehrere Beiträge zu ein- und demselben Signal gibt (z.B. wegen einer leitenden 
Verbindung), dann wird aus diesen Beiträgen mit Hilfe einer Auflösungsfunkti- 
on (engl. resolution function) ein resultierender Wert berechnet. Auf diese Weise 
wird die sup-Funktion, die im Kontext der CSA-Theorie vorgestellt wurde, be- 
rechnet, wenn es entsprechende Verbindungen gibt. 

Um zukünftige Werte zu berechnen, verwenden Simulatoren eine Warteschlan- 
ge von Ereignissen, die nach dem aktuellen Zeitpunkt eintreten sollen. Diese 
Warteschlange ist aufsteigend nach der Zeit sortiert, zu der diese zukünftigen Er- 
eignisse (z.B. die Aktualisierung eines Signals) stattfinden sollen. Die Ausführung 
einer Signalzuweisung führt dazu, dass Einträge in dieser Warteschlange erzeugt 
werden. Jeder dieser Einträge enthält den zugehörigen Ausführungszeitpunkt, das 
betroffene Signal und den zuzuweisenden Wert. Bei Signalzuweisungen, die kei- 
nerlei after-Bedingung beinhalten (erste mögliche Syntaxform der obigen Liste), 
verwendet der Eintrag die aktuelle Simulationszeit als Zeitpunkt, zu dem diese 
Zuweisung stattfinden soll. In diesem Fall findet die entsprechende Änderung 
nach einer unendlich kleinen Zeitspanne, ö-Verzögerung genannt (siehe unten), 
statt. Dies ermöglicht es, die Signale zu aktualisieren, ohne die makroskopische 
Sicht der Zeit zu verändern. 

Bei Signalzuweisungen, die einen transport-Präfix verwenden (zweite Form der 
Liste) wird die Signalzuweisung um die angegebene Dauer verzögert. Diese Form 
der Zuweisung folgt dem sogenannten Transportverzögerungsmodell. Dieses 
Modell simuliert das Verhalten einfacher Leitungen: diese verzögern (in erster 
Näherung) Signale. Auch kurze Impulse setzen sich entlang von Leitungen fort. 
Das Transportverzögerungsmodell kann auch für logische Schaltungen verwendet 
werden, auch wenn sein Hauptzweck die Modellierung von Leitungen ist. 


Beispiel 2.32: Modell eines ODER-Gatters mit Transportverzögerung: 


c <= transport a or b after 10 ns; 


Ein solches Modell würde auch kurze Impulse weiterleiten (siehe Abb. 2.70). 


_ ~ Impuls von 5 ns ; 
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Abb. 2.70 Gatter mit Transportverzögerung 
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Das Ausgangssignal c enthält einen kurzen Impuls von 5 ns, der bei einer Träg- 
heitsverzögerung (siehe unten) unterdrückt werden würde. V 


Signalzuweisungen mit Angabe der Transportverzögerung löschen alle Einträge 
in der Warteschlange, die dem Zeitpunkt der berechneten Aktualisierung und 
den darauf folgenden Zeitpunkten entsprechen. Wenn wir also zuerst eine Zuwei- 
sung mit recht großer Verzögerung und danach eine mit kleinerer Verzögerung 
ausführen, dann wird der Eintrag, der durch die erste Zuweisung entstanden ist, 
gelöscht. 

Bei Signalzuweisungen mit einer after-Bedingung, die keinen transpor t-Präfix 
enthalten, wird eine Trägheitsverzögerung angenommen. Dieses Verzögerungs- 
modell entspricht der Tatsache, dass auch echte Schaltungen über eine gewisse 
„Lrägheit” verfügen. Das bedeutet, dass kurze Impulsspitzen unterdrückt werden. 
Bei der dritten angegebenen Zuweisungsform werden alle Signaländerungen un- 
terdrückt, die kürzer als die angegebene Verzögerungsdauer anliegen. Die vierte 
Form entfernt dagegen alle Signaländerungen, die kürzer als die angegebene Zeit 
time anliegen, aus dem vorhergesagten Signalverlauf. Die etwas subtilen Regeln 
für das Löschen von Signaländerungen in der Liste künftiger Ereignisse sollen 
hier nicht wiedergegeben werden. 


Beispiel 2.33: Wir modellieren ein einfaches ODER-Gatter mit Trägheitsverzö- 
gerung: 


c <= a or b after 10 ns; 


Im Modell der Trägheitsverzögerung werden kurze Signalspitzen unterdrückt 
(siehe Abb. 2.71). 


N 
a 
b 
c u ee: 
` Kein Impuls von 5 ns z 
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Abb. 2.71 Gatter mit Trägheitsverzögerung 


Für das Ausgabesignal c gibt es keinen kurzen Impuls von 5 ns, aber der Impuls 
mit einer Länge von 15 ns erreicht den Ausgang. V 
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VHDL-Prozesse 


Zuweisungen sind nur eine Kurzform von VHDL-Prozessen. Mehr Kontrolle tiber 
die Auswertung von Signalen hat man mit expliziten Prozessen. Die allgemeine 
Syntax fiir Prozesse ist wie folgt: 


Marke: -- optional 
process 

Deklarationen -- optional 
begin 

Anweisungen -- optional 


end process; 


Zusätzlich zu Zuweisungen können Prozesse wait-Anweisungen enthalten. Diese 
Anweisungen können verwendet werden, um einen Prozess zu suspendieren. Es gibt 
die folgenden verschiedenen wait-Anweisungen: 


wait on Signalliste; -- suspendiere bis eines der Signale sich ändert 
wait until Bedingung; -- suspendiere bis die Bedingung erfüllt ist 
wait for Dauer; -- suspendiere für eine bestimmte Zeit 
wait; -- suspendiere unbegrenzt 


Alternativ zur Verwendung expliziter wait-Anweisungen kann eine Liste von 
Signalen im Prozesskopf angegeben werden. Diese bewirken, dass der Prozess jedes 
Mal aktiviert wird, wenn mindestens eines der Signale in der Liste seinen Wert 
ändert. 


Beispiel 2.34: Das folgende Modell eines UND-Gatters führt seine Anweisungen 
einmal aus und startet jedes Mal von vorne, wenn einer der Eingänge seinen Wert 
ändert: 


process(x,y) begin 
prod <= x and y; 
end process; 


Dieses Modell entspricht 


process begin 
prod <= x and y; 
wait on x,y; 

end process; 


mit einem expliziten wait-Statement am Ende. Vv 


Der VHDL-Simulationszyklus 


Im Standard-Dokument [241] zu VHDL wird die Ausführung eines VHDL- 
Prozesses wie folgt beschrieben: „Die Ausführung eines Modells besteht aus einer 
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Initialisierungsphase, danach folgt die wiederholte Ausfiihrung von Prozessen, 
die in der Beschreibung des Modells enthalten sind. Jede solche Wiederholung heißt 
Simulationszyklus. In jedem Zyklus werden die Werte aller Signale in der Prozess- 
Beschreibung berechnet. Falls aufgrund dieser Ergebnisse ein Ereignis auf einem 
bestimmten Signal stattfindet, so werden Prozesse, die auf dieses Signal sensitiv 
sind, aufgeweckt und innerhalb desselben Simulationszyklus ausgeführt.” 

Die Initialisierungsphase berücksichtigt die angegebenen Initialisierungswerte 
für Signale und Variablen und führt jeden Prozess einmal aus. Sie wird im Standard 
wie folgt beschrieben?®: 


e „Der treibende Wert und der effektive Wert jedes explizit deklarierten Signals 
werden berechnet und der aktuelle Wert des Signals wird auf den effektiven 
Wert gesetzt. Es wird angenommen, dass das Signal diesen Wert bereits für eine 
unendlich lange Zeit vor dem Start der Simulation hatte. ... 

e Jeder ... Prozess des Modells wird ausgeführt, bis er suspendiert wird. ... 

e Die Zeit des nächsten Simulationszyklus T,, (der in diesem Fall der erste Simu- 
lationszyklus ist) wird anhand der Regeln von Schritt e des Simulationszyklus 
(s.u.) berechnet.” 


Jeder Simulationszyklus beginnt damit, dass die aktuelle Zeit auf denjenigen 
nächsten Zeitpunkt gesetzt wird, an dem Änderungen berücksichtigt werden müssen. 
Diese Zeit T,, wurde entweder während der Initialisierungsphase oder während der 
letzten Ausführung eines Simulationszyklus berechnet. Die Simulation wird beendet, 
wenn die aktuelle Zeit den Maximalwert TIME’HIGH erreicht. Im Originaldoku- 
ment wird der Simulationszyklus wie folgt beschrieben: „Ein Simulationszyklus 
besteht aus den folgenden Schritten: 


a) Die aktuelle Zeit Te wird auf 7,, gesetzt. Die Simulation ist beendet, wenn T = 
TIME’ HIGH ist und wenn es keine aktuellen Treiber oder aufgeweckte Prozesse 
zur Zeit T, gibt. 

b)Jedes aktive explizite Signal im Modell wird aktualisiert. (Daraus können sich 
Ereignisse ergeben)” ... 

Im vorhergehenden Zyklus wurden neue zukünftige Werte für einige der Signale 
berechnet. Wenn T, dem Zeitpunkt entspricht, an dem diese Werte gültig wer- 
den, werden sie jetzt zugewiesen. Man beachte, dass neue Werte für Signale 
niemals sofort innerhalb des Simulationszyklus zugewiesen werden. Sie werden 
frühestens vor dem nächsten Simulationszyklus zugewiesen. Signale, die ihren 
Wert verändern, verursachen sogenannte Ereignisse, die ihrerseits wiederum die 
Ausführung von Prozessen anstoßen können, die auf diese Signale sensitiv sind. 

c) „Jeder Prozess P, der gerade auf ein Signal S sensitiv ist, wird aufgeweckt, wenn 
in diesem Simulationszyklus ein Ereignis auf dem Signal S stattgefunden hat.” 

d) „Jeder ... Prozess, der im aktuellen Simulationszyklus aufgeweckt wurde, wird 
solange ausgeführt, bis er suspendiert wird.” 


20 Implizit deklarierte Signale und sogenannte ,, postponed processes“, die in der 1997er-Version 
von VHDL eingeführt wurden, werden hier nicht betrachtet. 
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e) „Die Zeit 7,, des nächsten Simulationszyklus wird bestimmt als frühester Zeit- 
punkt, an dem 


1. TIME’ HIGH erreicht wird (das Ende der Simulationszeit), 

2. ein Signaltreiber aktiv wird (der nächste Zeitpunkt, an dem ein Treiber einen 
neuen Wert angibt) oder 

3. ein Prozess aufgeweckt wird” (diese Zeit wird durch wait for-Anweisungen 
bestimmt). 


„Wenn Tn = Te, dann ist der nächste Simulationszyklus (wenn es einen gibt) ein 
Delta-Zyklus.” 


Die iterative Form von Simulationszyklen wird in Abb. 2.72 gezeigt. 


Abb. 2.72 VHDL Beginn der Simulation 
Simulationszyklen 
Zukünftige Werte für Signaltreiber 


2O TN 


Zuweisung neuer Werte an Signale Auswerten der Prozesse 


Aktivieren aller auf geänderte Signale sensitiven Prozesse 


Delta (6)-Simulationszyklen sind eine Quelle vieler Diskussionen. Ihr Sinn ist es, 
eine infinitesimal kleine Verzögerung zu erzeugen, selbst wenn der Benutzer keine 
Verzögerung angegeben hat. 


Beispiel 2.35: Wir kommen auf unser Flipflop-Beispiel zurück. Abb. 2.73 zeigt das 
Flipflop mit Standard-Schaltkreissymbolen. 


Abb. 2.73 RS-Flipflop s — A , 
n 


Das Flipflop wird in VHDL wie folgt modelliert: 
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entity RS_Flipflop is 


port (R: in BIT; -- Rücksetz-Eingang 
S: in BIT; -- Setz-Eingang 
Q: inout BIT; -- Ausgang 
nQ:inout BIT;); -- invertierter Ausgang 


end RS_Flipflop; 
architecture one of RS_Flipflop is 
begin 

process: (R,S,Q,nQ) 

begin 

Q <= R nor nQ; nQ <= S nor Q; 
end process; 

end one; 


Die Ports Q und nQ müssen vom Typ inout sein, da sie auch intern gelesen 
werden, was mit Ports vom Typ out nicht möglich ist. Tabelle 2.5 zeigt die Simula- 
tionszeitpunkte, an denen die Signale dieses Modells aktualisiert werden. 


Tabelle 2.5 ö-Zyklen <Ons | Ons | Ons+6 | Ons+2 + 6 | Ons+3 * 6 
fiir ein RS-Flipflop RI '@' | '1' 4! "4! aq! 
s| 'Q' |'o'| '@' "Q' "Q' 
Q '1' | 1") '0' "Q' "Q' 
nQ| 'o' |'@'|] '0' 1% "1° 


In jedem Zyklus werden Aktualisierungen durch eines der Gatter geleitet. Die 
Simulation endet nach drei ö-Zyklen. Dabei ändert der letzte Zyklus nichts mehr, da 
Q bereits den Wert '®' hat. V 


ö-Zyklen entsprechen einer infinitesimal kleinen Zeiteinheit, die in Wirklichkeit 
immer vorhanden ist. ö-Zyklen stellen sicher, dass die Simulation die Kausalitat 
erhält. 

Die Ergebnisse hängen nicht von der Reihenfolge ab, in der Teile eines Modells 
während der Simulation ausgewertet werden. Dies wird durch die Trennung der 
Berechnung neuer Werte für Signale und deren eigentlicher Zuweisung erreicht. In 
einem Modell, das die folgenden Zeilen enthält, 


a <= b; 

b <= a; 
werden die Signale a und b stets vertauscht. Wenn die Zuweisungen sofort ausgeführt 
würden, so würde das Ergebnis von der Reihenfolge abhängen, in der die beiden 
Wertzuweisungen ausgeführt werden (siehe dazu auch Seite 63). VHDL-Modelle 
sind daher deterministisch. Dies erwarten wir auch von der Simulation einer echten 
Schaltung mit festem Verhalten. 

Es kann unbeschränkt viele 6-Zyklen geben, bevor die Zeit Te fortschreitet. Die 
Möglichkeit unbegrenzter Schleifen kann verwirrend sein. Eine Option zur Vermei- 
dung dieser Schleifen wäre es, Verzögerungen von Null, wie wir sie in unserem 
Modell benutzt haben, zu vermeiden. 
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Die Weiterleitung von Werten mittels Signalen ermöglicht auch eine einfache 
Implementierung des Observer-Musters (siehe Seite 37). Im Vergleich zu SDL ist 
bei VHDL die Anzahl der Beobachter variabel und hängt von der Anzahl der Prozesse 
ab, die auf die Änderung eines Signals warten. 

Wie sieht nun das Kommunikationsmodell hinter VHDL aus? Die Beschreibung 
der Semantik von VHDL basiert grundlegend auf einer einzelnen, zentralisierten 
Warteschlange für zukünftige Ereignisse, die alle zukünftigen Signalwerte spei- 
chert. Der Sinn dieser Warteschlange ist nicht, asynchronen Nachrichtenaustausch 
zu implementieren. Vielmehr soll der Simulationskern Einträge sequentiell aus der 
Warteschlange auslesen. Versuche, VHDL-Simulation verteilt auszuführen, leiden 
i.d.R. an mangelnder Performanz. Alle modellierten Komponenten können auf Wer- 
te von Signalen und Variablen zugreifen, die sich in ihrem Bereich befinden, ohne 
nachrichtenbasierte Kommunikation zu verwenden. Daher neigen wir dazu, die Im- 
plementierung von Kommunikation in VHDL als shared memory-basiert anzusehen. 
Auf Basis des VHDL-Simulators ließe sich aber auch FIFO-basierter Nachrichten- 
austausch in VHDL implementieren. 


IEEE 1164 


In VHDL gibt es keine vordefinierte Menge von Signalwerten, bis auf die Basis- 
unterstützung für zweiwertige Logik. Stattdessen kann man die zu verwendende 
Wertemenge in VHDL selbst definieren und unterschiedliche VHDL-Modelle kön- 
nen unterschiedliche Signal-Wertemengen verwenden. 

Würde diese Fähigkeit von VHDL allerdings in dieser Weise eingesetzt, wä- 
ren die Übertragbarkeit und Austauschbarkeit von VHDL-Modellen stark einge- 
schränkt. Um das Austauschen von Modellen zu vereinfachen, wurde eine Standard- 
Wertemenge definiert und von der IEEE standardisiert. Dieser Standard heißt IEEE 
1164 und wird von vielen Systemen eingesetzt. IEEE 1164 hat neun Werte: {'®', 
'1','L', 'H','X', 'W', 'Z', 'U', '-' }. Die ersten sieben Werte entsprechen den sie- 
ben Signalwerten von Abschnitt 2.7.2. 'U' steht für einen nicht-initialisierten Wert. 
Er wird von Simulatoren für Signale verwendet, die noch nicht explizit definiert 
wurden. 

'-' steht für eine beliebige Eingabe (engl. input don’t care). Dieser Wert muss 
näher erläutert werden. Hardwarebeschreibungsspachen werden häufig zur Beschrei- 
bung Boolescher Funktionen verwendet. Mit Hilfe der VHDL-select-Anweisung 
ist das bequem möglich. Die select-Anweisung entspricht den switch- und case- 
Anweisungen anderer Programmiersprachen. Die Bedeutung des VHDL-select ist 
jedoch anders als die Bedeutung der select-Anweisung in Ada (siehe Seite 124). 


Beispiel 2.36: Angenommen, wir wollen die Boolesche Funktion 


f(a,b,c) = ab + be 
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beschreiben. Weiterhin nehmen wir an, dass f für den Fall a = b = c ='O' 
undefiniert sein soll. Eine sehr bequeme Methode, dies in VHDL zu beschreiben, 
wäre der folgende Code-Ausschnitt: 


f <= select a&b&c -- & ist die Konkatenation 
'1' when "10-" -- erster Term 
'1' when "-11" -- zweiter Term 
'X' when "000" 


So könnten gegebene Funktionen leicht in VHDL umgesetzt werden. Leider 
drückt die select-Anweisung hier etwas vollkommen Anderes aus: Da IEEE 1164 
nur eine von vielen möglichen Wertemengen darstellt, kann VHDL kein Wissen 
über die „Bedeutung“ von '-' haben. Wenn VHDL-Compiler Konstrukte wie die 
oben gezeigte select-Anweisung übersetzen, prüfen sie, ob der zu betrachtende 
Ausdruck (im Beispiel a & b &c) den Werten in den when-Teilen entspricht. Genauer 
gesagt überprüfen sie, ob z.B. a&b&c gleich "19-" ist. In diesem Zusammenhang 
verhält sich '-' wie jeder andere Logikwert auch: VHDL-Systeme überprüfen, ob 
c den Wert '-' hat. Da der Wert '-' niemals irgendeiner der Variablen zugewiesen 
wird, werden diese Bedingungen nie erfüllt. V 


Daher ist der Wert '-' nur von begrenztem Nutzen. Die Nichtverfügbarkeit 
eines praktischen Wertes für eine beliebige Eingabe ist der Preis, den man für die 
Flexibilität bei der Definition von Wertemengen in der Programmiersprache VHDL 
bezahlen muss?!. 

Eine positive Eigenschaft der beschriebenen allgemeinen Betrachtungen von Sei- 
te 98 bis Seite 103 ist die Tatsache, dass man daraus direkt Schlussfolgerungen 
bezüglich der Ausdrucks- und Modellierungsfähigkeit des Standards IEEE 1164 
ziehen kann. Der IEEE-Standard basiert auf der 7-elementigen Signalwertmenge 
von Seite 100 und kann daher Schaltungen mit Verarmungstransistoren modellie- 
ren. Eine Modellierung von vorgeladenen Busleitungen ist damit allerdings nicht 
möglich. 


2.7.7 Verilog and SystemVerilog 


Verilog [539] ist eine weitere Hardware-Beschreibungssprache. Ursprünglich war 
es eine proprietäre Sprache, wurde aber später als IEEE Standard 1364 vereinheit- 
licht. Die Versionen heißen IEEE Standard 1364-1995 (Verilog Version 1.0) und 
IEEE Standard 1364-2001 (Verilog 2.0). Einige Eigenschaften von Verilog sind 
VHDL sehr ähnlich. Genau wie in VHDL werden Entwürfe als miteinander ver- 
bundene Design-Entities beschrieben, diese können wiederum verhaltensorientiert 


2! Dieses Problem wurde in VHDL 2006 beseitigt [342]. 

22 Abgesehen von dem Fall, in dem man keine Verarmungstransistoren einsetzt. In diesem Fall 
könnte man die schwachen Werte als auf den Leitungen gespeicherte Ladungen interpretieren. 
Dies ist allerdings nicht sehr praktisch, da Verarmungstransistoren heute in den meisten Systemen 
eingesetzt werden. 
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beschrieben werden. Prozesse werden zur Modellierung der Nebenlaufigkeit von 
Hardwarekomponenten verwendet. Genau wie in VHDL gibt es Bitvektoren und 
Zeiteinheiten. In einigen Bereichen ist Verilog allerdings weniger flexibel und kon- 
zentriert sich mehr auf bequem verwendbare Grundfunktionen. Standard-Verilog 
erlaubt es beispielsweise nicht, Aufzählungstypen so flexibel zu definieren wie dies 
im IEEE 1164-Standard der Fall ist. Die Unterstützung für vierwertige Logik ist 
direkt in die Verilog-Sprache eingebaut und der Standard IEEE 1364 stellt auch 
eine mehrwertige Logik mit acht verschiedenen Signalstärken zur Verfügung. Mehr- 
wertige Logik ist in Verilog enger an die Sprache gebunden als in VHDL. Das 
Logik-System von Verilog bietet auch mehr Funktionen für die Beschreibung von 
Schaltungen auf der Transistor-Ebene. Trotzdem ist VHDL im Allgemeinen flexibler. 
So kann man in VHDL etwa Hardware-Komponenten in Schleifen instantiieren, wo- 
durch man strukturelle Beschreibungen wie z.B. einen n-Bit-Addierer spezifizieren 
kann, ohne wirklich n Addierer und ihre Verbindungen explizit angeben zu müssen. 

Die Anzahl der Benutzer von Verilog ist ähnlich hoch wie die von VHDL. Wäh- 
rend VHDL in Europa beliebter ist, wird Verilog in den Vereinigten Staaten bevor- 
zugt. 

Die Versionen 3.0 und 3.1 von Verilog sind auch als SystemVerilog bekannt. Sie 
enthalten zahlreiche Erweiterungen zu Verilog 2.0, u.a. [245, 517]: 


e zusätzliche Sprachelemente, um Verhalten zu modellieren, 

e C-Datentypen wie int und Methoden zur Typdefinition wie typedef und struct, 

e Definition der Schnittstellen von Hardwarekomponenten als eigenständige Enti- 
ties, 

e standardisierte Methoden zum Aufruf von C/C++-Funktionen und, zu einem 
gewissen Grad, zum Aufruf eingebauter Verilog-Funktionen aus C, 

e deutlich verbesserte Unterstützung zur Beschreibung der Umgebung (der Test- 
bench) für die entwickelte Hardware (die als Circuit Under Design (CUD) be- 
zeichnet wird) und zur Verwendung der Testbench, um die CUD durch Simulation 
zu verifizieren, 

e Klassen (wie man sie von der objektorientierten Programmierung her kennt), die 
in Testbenches verwendet werden können, 

e dynamische Erzeugung von Prozessen, 

e standardisierte Interprozesskommunikation und -synchronisation, auch mit Se- 
maphoren, 

e automatische Anforderung und Freigabe von Speicher, 

e Sprachelemente, welche die Schnittstellen zu formalen Verifikationsmethoden 
vereinheitlichen (siehe Seite 261). 


Aufgrund der Schnittstellen zu C und C++ ist es auch möglich, Verilog mit 
SystemC zu verbinden. Die Simulations- und formalen Verifikationsmöglichkeiten 
machen die Sprache beliebt. 
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2.8 Von-Neumann-Sprachen 


Die sequenzielle Ausführung ist die gemeinsame Eigenschaft aller von-Neumann- 
Sprachen. Solche Sprachen erlauben zudem meist einen fast unbeschränkten Zugriff 
auf globale Variablen. Auch wenn der modellbasierte Entwurf mit kommunizieren- 

den endlichen Automaten und Berechnungsgraphen für eingebettete Systeme deut- 

lich besser geeignet ist, sind von-Neumann-Sprachen immer noch weit verbreitet. 

Daher können wir diese Sprachen nicht ignorieren. Die Unterscheidung zwischen 

KPNs und mit geeigneten Beschränkungen versehenen von-Neumann-Sprachen wird 

allerdings immer unschärfer. Bei KPNs wird auch von der sequenziellen Ausfüh- 

rung von Code in jedem der Knoten ausgegangen. Wir behalten die Unterscheidung 

zwischen KPNs und von-Neumann-Sprachen aber weiterhin bei, da der Schwer- 

punkt von KPNs auf der Modellierung der Kommunikation liegt und Details der 
Ausführung in den einzelnen Knoten unwichtig sind. Die ersten beiden in diesem 

Abschnitt behandelten Sprachen verfügen über Kommunikationsmechanismen. Der 
Schwerpunkt der restlichen Sprachen liegt bei Berechnungen, die Kommunikation 

kann durch den Einsatz verschiedener Bibliotheken realisiert werden. 


2.8.1 CSP 


CSP [218] (engl. Communicating Sequential Processes, kommunizierende se- 
quentielle Prozesse) ist eine der ersten Sprachen, die Mechanismen für Inter- 
prozesskommunikation enthalten. Die Kommunikation basiert auf Kanälen. 


Beispiel 2.37: Wir betrachten die Ein- und Ausgabe für den Kanal c : 


process A process B 

var a var b 

à f= 35 u. 

c!a; -- Ausgabe auf Kanal c c?b; -- Eingabe von Kanal c 
end; end; 


Beide Prozesse warten, bis der jeweils andere Prozess bei der Eingabe- bzw. 
Ausgabeanweisung angekommen ist. Diese Form der Kommunikation bezeichnet 
man als Rendez-Vous-Konzept oder als blockierende Kommunikation. V 


CSP ist deterministisch, da es, wie Kahn-Prozessnetzwerke auch, auf Eingaben 
von einem bestimmten Kanal wartet. 

CSP war die Grundlage für die Sprache OCCAM, die als Programmiersprache 
für Transputer [436] eingeführt wurde. Die Idee, einen Prozessor mit Kommuni- 
kationskanälen zu entwerfen, wurde beim XS1-Prozessor wiederverwendet [603]. 
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2.8.2 Ada 


In den achtziger Jahren des zwanzigsten Jahrhunderts bemerkte das US-amerikani- 
sche Verteidigungsministerium, dass sowohl die Verlässlichkeit als auch die Wartbar- 
keit der Software in den militärischen Ausrüstungsgegenständen zu großen Proble- 
men werden könnten, wenn nicht strenge Regelungen eingeführt würden. Es wurde 
entschieden, dass alle Software in der gleichen Echtzeitsprache geschrieben werden 
sollte. Die Anforderungen an solch eine Sprache wurden formuliert. Da keine exis- 
tierende Sprache alle Anforderungen erfüllte, wurde eine neue Sprache entworfen. 
Die letztlich angenommene Sprache basiert auf PASCAL und heißt Ada (nach Ada 
Lovelace, die als die erste Programmiererin gilt). Ada’95 [288, 80] ist eine objektori- 
entierte Erweiterung des Original-Sprachstandards. Allerdings wurden inzwischen 
die Vorgaben zur Nutzung von Ada wieder gelockert. 

Ada hat die interessante Eigenschaft, dass man verschachtelte Prozesse (die in 
Ada Tasks heißen) deklarieren kann. Eine Task wird gestartet, wenn der Kontrollfluss 
in den Bereich verzweigt, in dem die Task deklariert wurde. 


Beispiel 2.38: Das folgende Beispiel ist aus Burns et al. [79] entnommen. Darin 
enthält die Prozedur example1 zwei lokale Tasks a und b. 


procedure example1 is 
task a; 
task b; 
task body a is 
-- lokale Deklarationen für a 
begin 
-- Anweisungen für a 
end a; 
task body b is 
-- lokale Deklarationen für b 
begin 
-- Anweisungen für b 
end b; 
begin 
-- Rumpf der Prozedur example] 
end; 


Tasks a und b werden gestartet, wenn der Kontrollfluss in den Rumpf verzweigt, 
d.h. sie werden vor der 1. Anweisung im Code von example] starten. Vv 


Das Kommunikationskonzept von Ada ist ein weiteres wichtiges Konzept. Es ba- 
siert ähnlich wie das Konzept bei CSP auf dem Rendez-Vous-Paradigma. Wenn zwei 
Tasks Informationen austauschen wollen, muss diejenige Task, die den „Treffpunkt“ 
zuerst erreicht, warten, bis auch der Kommunikationspartner den entsprechenden 
Punkt im Kontrollfluss erreicht hat. In der Ada-Syntax werden Prozeduren ver- 
wendet, um Kommunikation zu beschreiben. Prozeduren, die von anderen Tasks 
aufgerufen werden können, müssen mit dem Schlüsselwort entry gekennzeichnet 
werden. 
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Beispiel 2.39: Das folgende Beispiel ist ebenfalls aus Burns et al. [79] entnommen: 


task screen_out is 
entry call (val: character; x, y: integer); 
end screen_out; 


Task screen_out enthält eine Prozedur call, die von anderen Prozessen aufge- 
rufen werden kann. Eine andere Task kann diese Prozedur aufrufen, indem sie ihr 
den Namen der Task voranstellt: 


screen_out.call(’Z’,10,20); 


Die aufrufende Task muss warten, bis die aufgerufene Task einen Punkt im 
Kontrollfluss erreicht hat, an dem sie Aufrufe von anderen Tasks annimmt. Dieser 
Punkt wird mit dem Schlüsselwort accept markiert: 


task body screen_out is 

Er 
Se call (val: character; x, y: integer) do 
ait call; 

ani sercan out 


Offensichtlich sollte eine Task screen_out auch auf mehrere Aufrufe gleichzeitig 
warten können. Hierzu wird die Ada select-Anweisung verwendet. Beispiel: 


task screen_output is 
entry call_ch(val: character; x, y: integer); 
entry call_int(z, x, y: integer); 
end screen_out; 
task body screen_output is 
select 
accept call_ch ... do... 
end call_ch; 
or 
accept call_int ... do .. 
end call_int; 
end select; 


In diesem Fall wartet screen_out, bis call_ch oder call_int aufgerufen wird. V 


Durch die Verwendung der select-Anweisung ist Ada nichtdeterministisch. Ada 
war während einer Reihe von Jahren die Sprache der Wahl für die Programmierung 
vieler militärischer Ausrüstungsgegenstände, die in der westlichen Hemisphäre pro- 
duziert wurden. Aktuelle Informationen über Ada sind auf verschiedenen Webseiten 
zu finden (siehe z.B. [289]). 
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2.8.3 Kommunikationsbibliotheken 


Gewohnliche von-Neumann-Sprachen verfiigen tiber keinerlei eingebaute Kommu- 
nikationsfunktionen. Diese können aber durch Bibliotheken zur Verfügung gestellt 
werden. Es gibt einen Trend dahin, sowohl die Kommunikation innerhalb eines 
Systems wie auch Kommunikation über größere Entfernungen zu unterstützen. Zu- 
nehmend werden Internetprotokolle angewandt. 


MPI 


Die Programmierung von Mehrkern-Systemen ist mit dem sogenannten Message 
Passing Interface (MPI) möglich. MPI ist eine sehr häufig eingesetzte Bibliothek, 
die ursprünglich für Hochleistungsrechner entwickelt wurde. Sie basiert auf Nach- 
richtenaustausch und ermöglicht synchronen wie auch asynchronen Nachrichtenaus- 
tausch. 

Synchroner Nachrichtenaustausch ist beispielsweise mit Hilfe der Bibliotheksfunk- 
tion MPI_Send möglich [396]: 

MPI_Send(buffer, count, type, dest, tag, comm) mit: 


e buffer : Adresse der zu sendenden Daten, 

e count: Anzahl zu sendender Datenelemente, 

e type: zu sendender Datentyp (z.B. MPI_CHAR, MPI_SHORT, MPI_INT ), 

e dest : Prozess-ID des Zielprozesses, 

e tag: Nachrichten-ID (zur Sortierung ankommender Nachrichten), 

e comm: Kommunikationskontext (Menge von Prozessen, für die das Zielfeld gültig 
ist) und 

e Funktionsergebnis: gibt Erfolg oder Misserfolg an. 


Die folgende Funktion ist eine asynchrone Bibliotheksfunktion: 
MPI_Isend(buffer, count, type, dest, tag, comm, request) mit 


e buffer, count, type, dest, tag, comm: wie oben und 

e das System erzeugt zusätzlich eine eindeutige „Anfrage-Nummer”. Der Program- 
mierer kann diese in einer Warteroutine nutzen, um festzustellen, ob die nicht- 
blockierende Operation beendet wurde. 


Die Aufteilung von Rechenressourcen zwischen verschiedenen Prozessoren muss 
bei MPI explizit erfolgen, das Gleiche gilt für die Kommunikation und das Verteilen 
von Daten. Synchronisation ist implizit durch die Kommunikation, zusätzlich ist 
explizite Synchronisation möglich. Demzufolge ist ein Großteil des Verwaltungs- 
codes explizit zu implementieren, was einen großen Arbeitsaufwand für den Pro- 
grammierer bedeutet. Zudem skaliert dieser Ansatz nicht gut, wenn die Anzahl der 
Prozessoren sich nennenswert ändert [553]. 

Um MPI-artige Kommunikation auf Echtzeitsysteme anwenden zu können, wurde 
eine Echtzeit-Version von MPI definiert, MPI/RT genannt [501]. MPVRT deckt 
Funktionalität wie Thread-Erzeugung und -Beendigung nicht ab. MPI/RT wird als 
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mögliche Schicht zwischen dem Betriebssystem und Standard-(nicht-Echtzeit-) MPI 
angesehen. 

MPI ist für eine Vielzahl von Prozessoren verfügbar und wird auch für Mehrkern- 
Chips in Betracht gezogen. Jedoch basiert es auf der Annahme, dass Speicherzugriffe 
schneller als Kommunikationsoperationen sind. Zudem zielt MPI hauptsächlich auf 
homogene Mehrprozessorsysteme ab. Beide Annahmen sind für mehrere Prozesso- 
ren auf einem Chip nicht notwendigerweise gültig. 

MPI wurde kürzlich erweitert, um auch Kommunikation auf der Basis eines 
gemeinsamen Speichers abzudecken. 


OpenMP 


Bei OpenMP ist die Parallelität größtenteils explizit, wogegen die Aufteilung von 
Berechnungen, Kommunikation, Synchronisation usw. implizit stattfindet. Paralleli- 
tät wird durch Pragmas ausgedrückt: beispielsweise können Schleifen mit Pragmas 
versehen werden, die angeben, dass sie parallelisiert werden sollten. 


Beispiel 2.40: Das folgende Programm beinhaltet eine kleine parallele Schleife 
[439]: 


void al(int n, float *a, float xb) { 


int i; 

#pragma omp parallel for 

for GSI less acme) /* i ist standardmäßig privat */ 
bli] = (alil + ali-1]) / 2.0; 

} 


Ein einfaches Pragma reicht hier aus, um eine mögliche parallele Ausführung anzu- 
zeigen. V 


Dies bedeutet, dass OpenMP vom Benutzer nur einen kleinen Aufwand für die 
Parallelisierung verlangt. Dies bedeutet aber auch, dass der Benutzer die Partitionie- 
rung nicht kontrollieren kann [553]. Es existieren Anwendungen für Multiprozessor- 
Systeme auf SoCs, sogenannte MPSoCs (siehe z.B. [367]). 

Weitere Techniken für die Programmierung von Mehrkern-Prozessoren werden 
im Abschnitt über Systemsoftware vorgestellt werden (siehe Seite 253). 


2.8.4 Weitere Sprachen 


Die Sprache Java ist ursprünglich nicht für eingebettete Systeme entwickelt wor- 
den. Es gab Bemühungen, die daraus resultierenden Probleme zu lösen [12, 271]. 
Allerdings bleiben Android und Java für Chipkarten die einzigen wichtigen Anwen- 
dungen. Der Workshop JTRES über , Java Technologies for Real-time and Embedded 
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Systems” (siehe http://jtres2016.compute.dtu.dk/) spiegelt den letzten Stand des Ein- 
satzes von Java wider. 

Die Sprache Pearl [127] wurde fiir industrielle Kontrollanwendungen entwickelt. 
Sie beinhaltet viele Sprachelemente, um Prozesse zu kontrollieren, auch die Mo- 
dellierung von Zeit ist möglich. Pearl benötigt ein zugrunde liegendes Echtzeitbe- 
triebssystem. Die Sprache ist in Europa sehr beliebt gewesen, was sich in der groBen 
Anzahl von industriellen Steuerungsanwendungen zeigt, die in dieser Sprache imple- 
mentiert wurden. Pearl unterstützt Semaphore, die dazu verwendet werden können, 
die Kommunikation tiber gemeinsame Puffer zu schiitzen. 

Chill [592] wurde fiir Telefonvermittlungsstellen entworfen. Die Sprache wurde 
von der CCITT standardisiert und in Telekommunikationsgeräten verwendet. Chill 
ist eine Art erweitertes PASCAL. 

IEC 60848 [232] und STEP 7 [488] sind auf die Anwendung in der Regelungs- 
technik spezialisierte Sprachen. Beide Sprachen enthalten graphische Elemente zur 
Beschreibung der Funktionalität eines Systems. 


2.9 Ebenen der Hardware-Modellierung 


In der Praxis werden Entwürfe auf unterschiedlichen Abstraktionsebenen begonnen. 
In einigen Fällen wird auf einer hohen Abstraktionsebene das Gesamtverhalten des 
zu entwerfenden Systems beschrieben. In anderen Fällen beginnt die Spezifikation 
mit der Beschreibung einer elektrischen Schaltung auf einer entsprechend niedrige- 
ren Abstraktionsstufe. Für jede Abstraktionsebene gibt es eine Anzahl von Sprachen, 
einige Sprachen decken auch mehrere Abstraktionsebenen ab. Im Folgenden wird 
eine Menge von möglichen Abstraktionsebenen beschrieben. Einige der niedrigeren 
Abstraktionen werden hier nur der Vollständigkeit halber erwähnt — eine Spezifika- 
tion sollte nicht auf einer dieser Ebenen beginnen. Es folgt eine Liste von häufig 
verwendeten Bezeichnungen und Eigenschaften von Abstraktionsebenen: 


e Modelle auf Systemebene: Der Begriff Systemebene ist nicht klar definiert. Er 
wird hier verwendet, um das gesamte eingebettete System und das System, in das 
die Informationsverarbeitung integriert ist („das Produkt‘) zu beschreiben, und 
möglicherweise auch die physische Umwelt (z.B. die Straßenverhältnisse oder 
Wetterbedingungen) darstellen zu können. Offensichtlich beinhalten solche Mo- 
delle Aspekte sowohl der physischen Umgebung wie auch der Informationsverar- 
beitung und es kann schwierig sein, dafür passende Simulatoren zu finden. Mög- 
liche Lösungen sind die Verwendung von VHDL-AMS (die analoge Erweiterung 
von VHDL), SystemC , Modelica, COMSOL (siehe https://www.comsol.com/) 
oder MATLAB/Simulink. MATLAB und VHDL-AMS unterstützen die Model- 
lierung partieller Differentialgleichungen, eine der wichtigsten Anforderungen 
bei der Simulation physischer Systeme. Es ist eine große Herausforderung, die 
informationsverarbeitenden Bestandteile des Systems so zu modellieren, dass 
das Simulationsmodell auch zur Synthese des eingebetteten Systems verwendet 
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werden kann. Wenn das nicht möglich ist, muss unter Umständen eine fehleranfal- 
lige manuelle Übersetzung zwischen den verschiedenen Modellen durchgeführt 
werden. 

e Algorithmische Ebene: Auf dieser Ebene werden Algorithmen simuliert, die 
innerhalb des eingebetteten Systems zum Einsatz kommen sollen. Beispielsweise 
kann ein MPEG Video-Encoder simuliert werden, um die Ausgabequalität der 
Videos zu bestimmen. Bei der Verwendung solcher Simulationen gibt es keinen 
Bezug zum Befehlssatz des Zielprozessors. 

Datentypen können in der Simulation durchaus noch eine höhere Wortbreite 
haben als in der endgültigen Implementierung. Beispielsweise verwenden die 
Referenzimplementierungen des MPEG-Standards doppelt-genaue Gleitkomma- 
zahlen. Das endgültige eingebettete System wird solche Datentypen kaum verar- 
beiten können. Wenn die Datentypen so gewählt wurden, dass jedes Bit in der 
Simulation genau einem Bit in der Implementierung entspricht, so spricht man 
von einem bitgenauen Modell. Die Übersetzung von nicht-bitgenauen in bitge- 
naue Modelle sollte durch Hilfsprogramme unterstützt werden (siehe Seite 388). 


e Befehlssatzebene: In diesem Fall wurden die Algorithmen bereits für den Be- 
fehlssatz des zu verwendenden Prozessors (oder der Prozessoren) übersetzt. Si- 
mulationen auf dieser Ebene erlauben das Zählen der ausgeführten Instruktionen. 
Es gibt verschiedene Varianten der Befehlssatzebene: 


— In einem grobkörnigen Modell wird nur die Wirkung von Instruktionen simu- 
liert, das Zeitverhalten wird vernachlässigt. Die Informationen aus Assembler- 
Referenz-Handbüchern (die Befehlssatzarchitektur, Instruction Set Architec- 
ture (ISA)) sind fiir die Definition eines solchen Modells ausreichend. 

— Modellierung auf Transaktionsebene: Bei der Modellierung auf Transakti- 
onsebene werden Transaktionen, wie z.B. Bus-Lese- oder Schreiboperationen, 
sowie Kommunikationsvorgänge zwischen verschiedenen Komponenten mo- 
delliert. Diese Art der Modellierung enthält weniger Details als die zyklenge- 
naue Modellierung (s.u.), daher können hier deutliche Vorteile bei der Simu- 
lationsgeschwindigkeit erzielt werden [105]. 

— In einem feinkörnigeren Modell kann man eine zyklengenaue Befehlssatzsi- 
mulation erreichen. In diesem Fall kann die genaue Zyklenzahl, die zur Aus- 
führung einer Applikation benötigt wird, bestimmt werden. Zum Aufstellen 
von zyklengenauen Modellen braucht man sehr genaue Informationen über 
die Prozessorhardware, um z.B. eine Fließband-artige Befehlsverarbeitung, 
Ressourcenkonflikte und Speicherwartezyklen richtig modellieren zu können. 


e Register-Transfer-Ebene (RTL): Auf dieser Ebene werden alle Komponenten 
auf der Register-Transfer-Ebene modelliert. Das beinhaltet arithmetisch/logische 
Einheiten (ALUs), Register, Speicher, Multiplexer und Dekodierer. Modelle auf 
dieser Ebene sind immer zyklengenau. Die automatische Synthese aus solchen 
Modellen heraus ist keine große Herausforderung. 

e Modelle auf Gatterebene: Hier enthalten die Modelle Gatter als Basisbausteine. 
Modelle auf Gatterebene erlauben genaue Aussagen über die Wahrscheinlich- 
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keiten einer Wertänderung von Signalen und können deshalb zur Energiebes- 
timmung herangezogen werden. Die Berechnung von Verzögerungen kann hier 
genauer durchgeführt werden als bei einem Modell auf RTL-Ebene. Allerdings 
ist während der Entwurfsphase üblicherweise keine Information über die Längen 
von Verbindungsleitungen und somit auch nicht über deren Kapazitäten verfüg- 
bar. Daher sind Verzögerungs- und Energiewerte auch auf dieser Ebene lediglich 
Schätzungen. 

Der Begriff „Gatterebene“ wird manchmal auch in Situationen verwendet, wo die 
Gatter lediglich dazu verwendet werden, um Boolesche Funktionen darzustellen. 
Gatter in einem solchen Modell repräsentieren aber nicht unbedingt physikalische 
Gatter. Es wird dann nur das Verhalten der Gatter betrachtet, nicht die Tatsache, 
dass sie in der späteren Realisierung physikalische Komponenten darstellen. Ge- 
nauer sollten solche Modelle eigentlich „Boolesche Funktionsmodelle“ heißen??, 
dieser Begriff ist aber nicht sehr weit verbreitet. 

e Modelle auf Schalterebene: Modelle auf Schalterebene verwenden Schalter 
(Transistoren) als Grundbausteine. Solche Beschreibungen verwenden Modelle 
digitaler Signalwerte (siehe Beschreibung möglicher Wertemengen ab Seite 97). 
Im Gegensatz zu Modellen auf Gatterebene können die Modelle auf Schalterebene 
den bidirektionalen Transfer von Informationen in Schaltungen abbilden. Für die 
Simulation wird häufig die ternäre Simulation eingesetzt [72]. 

e Modelle auf Schaltungsebene: Die Schaltungstheorie und ihre Bestandteile 
(Strom- und Spannungsquellen, Widerstände, Kondensatoren, Spulen und mög- 
licherweise Makromodelle von Halbleitern) bilden die Basis der Simulation auf 
dieser Ebene. Simulationen beinhalten partielle Differentialgleichungen. Diese 
Gleichungen sind nur dann linear, wenn das Verhalten der Halbleiter lineari- 
siert (approximiert) wird. Die am häufigsten verwendeten Simulatoren auf der 
Schaltungsebene sind SPICE [556] und dessen Varianten. 

e Modelle auf Layoutebene: Modelle auf Layoutebene zeigen das tatsächliche 
Layout der Schaltung. Solche Modelle beinhalten geometrische Informationen. 
Sie können nicht direkt simuliert werden, da die Geometrie keine konkreten An- 
haltspunkte für das Verhalten gibt. Das Verhalten kann erschlossen werden, wenn 
man das Modell auf Layoutebene gemeinsam mit einem verhaltensorientierten 
Modell auf einer höheren Ebene kombiniert, oder indem aus dem Layout die 
Schaltung extrahiert wird, wobei man Wissen über die Darstellung von Kompo- 
nenten auf der Layoutebene benötigt. In einem typischen Entwurfsablauf wer- 
den die Länge von Verbindungsleitungen und deren entsprechende Kapazitäten 
aus dem Layoutmodell extrahiert und in die Beschreibungen auf höherer Ebene 
zurück-annotiert (engl. back-annotated). Auf diese Weise kann die Genauigkeit 
von Verzögerungs- und Energieschätzungen verbessert werden. Layoutinforma- 
tionen können auch für die thermische Modellierung benötigt werden. 

e Modelle auf Prozess- und Schaltungs-Ebene: Auf einer noch niedrigeren Stu- 
fe kann man den Herstellungsprozess modellieren. Aufgrund der Information 
aus diesen Modellen kann man Parameter (z.B. Verstärkung und Kapazität) für 


23 Diese Modelle könnten mit Hilfe von binären Entscheidungsdiagrammen (Binary Decision 
Diagrams (BDD)) [570] dargestellt werden. 
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die verwendeten Bauelemente (Transistoren) berechnen. Man beachte, dass die 
Verwendung des Begriffs „Prozess“ in der Fertigungstechnologie mit unserer 
bisherigen Benutzung nicht kompatibel ist. 


2.10 Vergleich der Berechnungsmodelle 
2.10.1 Kriterien 


Berechnungsmodelle lassen sich anhand verschiedener Kriterien vergleichen. So 
vergleicht z.B. Stuijk [515] Berechnungsmodelle nach folgenden Kriterien: 


e Ausdrucksstärke und Kompaktheit zeigen an, welche Systeme modellierbar 
sind und wie kompakt diese Beschreibung ist. 

e Analysierbarkeit bezieht sich auf die Verfügbarkeit von Scheduling-Algorithmen 
und darauf, ob Unterstiitzung fiir Echtzeitsysteme vorhanden ist. 

¢ Die Implementierungseffizienz wird durch das benötigte Scheduling-Verfahren 
und die Codegröße beeinflusst. 


Abb. 2.74 zeigt eine Klassifikation von Datenflussmodellen anhand dieser Kriterien. 


Ausdrucksstarke und Kompaktheit 


Kahn-Prozessnetzwerke 
SDF 
Homogeneous SDF (HSDF) 


Analysierbarkeit Implementierungseffizienz 


Abb. 2.74 Vergleich von Datenflussmodellen 


Diese Abbildung verdeutlicht, dass Kahn-Prozessnetzwerke ausdrucksstark sind: 
sie sind Turing-vollständig, also kann jedes Problem, das von einer Turing-Maschine 
berechnet werden kann, auch von einem KPN berechnet werden. Turing-Maschinen 
werden als Standardmodell fiir universelle Computer verwendet [215]. Es ist aller- 
dings schwierig, Terminierungseigenschaften und obere Grenzen fiir Puffergrößen 
von KPNs zu analysieren. Dagegen sind SDF-Graphen und Cyclo-Static Data Flow 
(CSDF, siehe Seite 82) nicht Turing-vollständig, da sie nicht dazu in der Lage sind, 
Kontrollflüsse zu modellieren. Dafür lassen sich Verklemmungseigenschaften und 
obere Grenzen für Puffergrößen von SDF-Graphen einfacher analysieren. Homogene 
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SDF-Graphen (HSDF) (siehe Seite 82) sind noch weniger ausdrucksstark, aber noch 
einmal einfacher zu analysieren. 

Wir könnten Berechnungsmodelle auch in Hinblick auf die Arten von Prozessen, 
die unterstützt werden, vergleichen: 


e Die Anzahl von Prozessen kann entweder statisch oder dynamisch sein. Eine 
statische Anzahl von Prozessen vereinfacht die Implementierung und ist ausrei- 
chend, wenn jeder Prozess eine bestimmte Hardwarekomponente modelliert und 
wir hot plugging (das Hinzufügen von Hardware zur Laufzeit) nicht berücksich- 
tigen. 

e Prozesse können entweder statisch verschachtelt sein oder alle Prozesse sind auf 
gleicher Ebene deklariert. Beispielsweise ermöglicht StateCharts die verschach- 
telte Deklaration von Prozessen, wogegen SDL (siehe Seite 68) dies nicht erlaubt. 
Die Verschachtelung erlaubt es, Belange zu verkapseln. 

e Es gibt verschiedene Techniken zur Prozesserzeugung. Prozesse können durch 
eine Analyse der Prozessdeklarationen im Sourcecode, durch den fork- und join- 
Mechanismus (der z.B. von Unix unterstützt wird) und auch durch explizite 
Funktionen zur Prozesserzeugung erzeugt werden. 


Die Ausdrucksstärke der verschiedenen datenflussorientierten Berechnungsmo- 
delle ist auch in Abb. 2.75 [41]. dargestellt. In diesem Buch nicht aufgeführte Be- 
rechnungsmodelle sind dabei durch gestrichelte Linien dargestellt. 


Abb. 2.75 Ausdrucksstärke 
von Datenflussmodellen 


Keines der Berechnungsmodelle und keine der bisher vorgestellten Sprachen er- 
füllt alle Anforderungen an eine Spezifikationssprache für eingebettete Systeme. 
Tabelle 2.6 gibt einen Überblick über einige der wichtigsten Eigenschaften ausge- 
wählter Sprachen. 

SpecC und SystemC erfüllen alle aufgeführten Anforderungen. Allerdings bein- 
haltet diese Liste einige andere Anforderungen nicht, wie z.B. die präzise Angabe von 
Deadlines. Es ist sehr unwahrscheinlich, dass ein bestimmtes Berechnungsmodell 
oder eine bestimmte Sprache jemals alle Anforderungen erfüllen wird, da einige der 
Anforderungen im Konflikt zueinander stehen. Eine Sprache, die harte Echtzeitan- 
forderungen unterstützt, mag weniger dafür geeignet sein, Systeme mit weniger 
harten Echtzeitanforderungen zu beschreiben. Eine Sprache, die für verteilte Rege- 
lungsanwendungen gedacht ist, mag sich schlecht für lokale Datenfluss-dominierte 
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Tabelle 2.6 Vergleich von Sprachen 


Verhaltens-|Strukturelle|Programmier-\Unterstützung |Dynamische 
Hierarchie |Hierarche |sprachen- von Ausnahme-|Prozess- 
Sprache elemente behandlung erzeugung 
StateCharts |+ - - + - 
VHDL + + + - - 
SDL +- +- +- - + 
Petri-Netze |- - - - + 
Java + - + + + 
SpecC + + + + + 
SystemC |+ + + + + 
Ada + - + + + 


Anwendungen eignen. Daher ist damit zu rechnen, dass wir Kompromisse in Kauf 
nehmen miissen. 

Welche Kompromisse kommen nun in der Praxis zum Einsatz? Programmieren 
in Assemblersprache war in der Anfangszeit eingebetteter Systeme sehr verbreitet. 
Die Programme waren klein genug, um die Komplexität der Probleme auch in 
Assembler zu beherrschen. Der nächste Schritt war die Verwendung von C und mit C 
verwandten Sprachen. Die weiter steigende Komplexität eingebetteter Systeme (siehe 
Seite 18) wird dazu führen, dass Sprachen auf einer höheren Ebene anstelle von C 
eingesetzt werden. Diese nächste Abstraktionsebene wird z.B. von objektorientierten 
Sprachen oder SDL abgedeckt. Sprachen wie UML werden ebenfalls benötigt, damit 
Spezifikationen in frühen Entwurfsphasen festgehalten werden können. Ein Trend 
geht hin zu modellbasiertem Entwurf [477]. In der Praxis lassen sich diese Sprachen 
wie in Abb. 2.76 gezeigt verwenden. 


(RT-) UML oder äquivalent (RT-) UML oder äquivalent 
y 
SDL (RT-) Java 
Vs QP dl | AEII 
C-Programme VHDL Ji 
y 
Assembler-Programme Netzliste 
y y 
Objekt-Code Hardware | | Objekt-Code 


Abb. 2.76 Verwendung von Sprachen in Kombination 


Nach Abb. 2.76 lassen sich Sprachen wie SDL oder StateCharts nach C über- 
setzen. Diese Beschreibungen können dann compiliert werden. Ein mit SDL oder 
StateCharts begonnener Entwurf ermöglicht auch die Implementierung von Funk- 
tionalität in Hardware, wenn Übersetzer von diesen Sprachen in eine Hardwarebe- 
schreibungssprache wie VHDL zur Verfügung stehen. Sowohl C wie auch VHDL 
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werden auf absehbare Zeit noch als Zwischensprachen verwendet werden. Java be- 
nötigt keine Zwischenschritte, profitiert aber auch von ausgereiften Ubersetzungs- 
methoden in Maschinensprache. Auf ähnliche Weise lassen sich auch Übersetzungen 
zwischen verschiedenen Arten von Graphen realisieren. So können SDF-Graphen 
in eine Unterklasse von Petrinetzen übersetzt werden [515]. Sie entsprechen auch 
einer Unterklasse des computation graph model von Karp und Miller [283]. Die 
Verbindung der verschiedenen Berechnungsmodelle wird durch formale Methoden 
vereinfacht [95]. 

Eine Reihe von Sprachen zum Entwurf eingebetteter Systeme werden in einem 
von M. Radetzki herausgegebenen Buch [464] besprochen. Popovici et al. [457] 
verwenden eine Kombination von Simulink und SystemC. 

Weiterhin gibt es noch algebraische Sprachen wie LOTOS [257] und Z [504], die 
präzise Spezifikationen erlauben, die aber nicht ausführbar sind. 


2.10.2 Unified Modeling Language (UML) 


Die Sprache UML" beinhaltet Diagramme, die verschiedenen Berechnungsmodellen 
entsprechen. Tabelle 2.7 zeigt eine Klassifikation der einzelnen bisher betrachteten 
UML-Diagrammarten in Hinblick auf die hier besprochenen Berechnungsmodelle. 


Tabelle 2.7 In UML™ verfügbare Berechnungsmodelle 


Kommunikation/ Gemeinsamer Speicher Nachrichtenaustausch 
Komponenten shared memory synchron asynchron 
Undefinierte Komponenten Anwendungsfälle (use cases) 


Sequenzdiagramme, Zeitdiagramme 
Differentialgleichungen - 


Endliche Automaten Zustandsdiagramme |- - 
Datenfluss - Datenflussdiagramme 
Petrinetze (nicht sinnvoll) Aktivitätsdiagramme 


Verteilte Ereignismodelle - - 
Von-Neumann-Modell - - 


Diese Abbildung stellt dar, inwieweit UML einige der besprochenen Berech- 
nungsmodelle abdeckt. Dabei liegt der Schwerpunkt auf frühen Entwurfsphasen. 
Die Semantik der Kommunikation ist meist nur unpräzise definiert, daher kann un- 
sere Klassifikation in dieser Hinsicht nicht genau sein. Zusätzlich zu den bereits 
erwähnten Diagrammen lassen sich die folgenden Diagramme modellieren: 


« Deployment-Diagramme: Diese Diagramme sind für eingebettete Systeme wich- 
tig: sie beschreiben die „Ausführungsarchitektur” von Systemen (Hardware- oder 
Softwareknoten). 

e Paketdiagramme: Paketdiagramme beschreiben die Partitionierung der Software 
in Softwarepakete. Sie ähneln den Moduldiagrammen in StateMate. 
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e Klassendiagramme: Diese Diagramme beschreiben Vererbungsbeziehungen 
zwischen Objektklassen. 

e Kommunikationsdiagramme (in UML 1.0 Kollaborationsdiagramme ge- 
nannt): Diese Graphen stellen Klassen, Relationen zwischen Klassen und zwi- 
schen diesen ausgetauschte Nachrichten dar. 

e Komponentendiagramme: Diese stellen die Komponenten von Anwendungen 
oder Systemen dar. 

e Objektdiagramme, Interaktions-Überblicks-Diagramme, zusammengesetz- 
te Strukturdiagramme: Diese drei Arten von Diagrammen werden seltener 
verwendet. Einige davon sind auch Spezialfalle anderer Diagramme. 


Die verfiigbaren Werkzeuge erlauben es in begrenzter Weise, die Konsistenz zwi- 
schen verschiedenen Diagrammarten zu tiberpriifen. Eine komplette Uberpriifung 
scheint aber unmöglich zu sein. Eine Ursache hierfür ist, dass die Semantik von 
UML ursprünglich nicht definiert wurde. Es wurde behauptet, dass dies absichtlich 
geschah, da die Beschäftigung mit genauer Semantik erst in späteren Entwurfsphasen 
erfolgen soll. Folglich lassen sich genaue ausführbare Spezifikationen nur dann aus 
einer UML-Beschreibung erzeugen, wenn UML mit einer weiteren Sprache kom- 
biniert wird. Einige verfügbare Werkzeuge kombinieren UML mit SDL [228] und 
C++. Es gibt aber auch erste Ansätze, die Semantik von UML zu definieren. 

Die Version 1.4 von UML war nicht für eingebettete Systeme entworfen worden. 
Daher fehlen dieser Version eine Reihe von Eigenschaften, die zur Modellierung 
eingebetteter System unerläßlich sind (siehe Seite 31). Insbesondere fehlen die fol- 
genden Eigenschaften [387]: 


e keine Partitionierung von Software in Tasks bzw. Prozesse, 

+ Zeitverhalten kann nicht beschrieben werden, 

e die wesentlichen Hardwarekomponenten eines Systems können nicht in die Be- 
schreibung integriert werden. 


Durch die weiter zunehmende Menge an Software in eingebetteten Systemen ge- 
winnt UML auch in diesem Bereich an Bedeutung. Es gibt daher verschiedene Vor- 
schläge für UML-Erweiterungen, die Echtzeitanwendungen unterstützen [387, 137]. 
Diese wurden in der Entwurfsphase von UML 2.0 berücksichtigt. UML 2.0 beinhal- 
tet 13 Arten von Diagrammen (im Vergleich zu 9 Arten in UML 1.4) [13]. Besondere 
Profile berücksichtigen die Anforderungen von Echtzeitsystemen [369]. Diese Pro- 
file beinhalten Klassendiagramme mit Beschränkungen, Icons, Diagrammsymbole 
und einige (partielle) Semantikbeschreibungen, lassen aber auch semantische Fragen 
offen. Es gibt UML-Profile für folgende Aspekte und Aufgaben [369]: 


e Schedulability, Leistung, und Zeitangaben [430], 

« Testen [434], 

e Dienstgüte (Quality of Service (QoS)) und Fehlertoleranz [434], 

e Systemmodellierung mit einer Sprache namens SysML [432], 

e Modellierung und Analyse von eingebetteten Echtzeitsystemen (MARTE) [431], 
e Interoperabilität von UML und SystemC [469], 

e Wiederverwendung von Intellectual Property (IP) mit dem SPRINT-Profil [505]. 
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Mit solchen Profilen lassen sich beispielsweise Sequenzdiagramme mit Zeitin- 
formationen ergänzen. Profile können aber zueinander inkompatibel sein. 


2.10.3 Ptolemy II 


Modellierung, Simulation und Entwurf mit verschiedenen Berechnungsmodellen 
und deren Kombination sind Ziel des Ptolemy-Projekts [460]. Eine Betonung liegt 
auf eingebetteten Systemen, die verschiedene Technologien und dementsprechend 
auch MoCs mischen. Beispielsweise können analoge und digitale Elektronik, Hard- 
und Software, elektrische und mechanische Geräte beschrieben werden. Ptolemy 
unterstützt verschiedene Anwendungen, einschl. der Signalverarbeitung, Regelungs- 
technik, sequentielle Entscheidungsunterstützung und Benutzerschnittstellen. Ein 
Schwerpunkt gilt der Erzeugung von eingebetteter Software. Die Kernidee besteht 
darin, die Software aus demjenigen Berechnungsmodell zu erzeugen, das für eine 
bestimmte Anwendung am geeignetsten ist. Die Version 2 von Ptolemy (Ptolemy 
II) kennt die folgenden Berechnungsmodelle und zugehörigen Anwendungsgebiete 
(siehe auch Seite 43): 


Kommunizierende sequenzielle Prozesse (CSP), 

. kontinuierliche Zeit (für mechanische Systeme und analoge Schaltungen), 
. diskretes Ereignismodell, 

. verteilte diskrete Ereignisse, 

. endliche Automaten (engl. Finite State Machines (FSM)), 

. Prozessnetzwerke (Kahn-Prozessnetzwerke, siehe Seite 76), 

. SDF (siehe Seite 68), 

. synchrone/reaktive Berechnungsmodelle. 


Nun RPwmN m 


Diese Liste macht deutlich, dass die Untersuchung verschiedener Berechnungs- 
modelle ein Schwerpunkt des Ptolemy-Projektes ist. 


2.11 Aufgaben 


Die folgenden Aufgaben sollten entweder zu Hause oder während einer Anwe- 
senheitsphase nach dem flipped classroom-Konzept bearbeitet werden. Bei diesem 
Konzept sind die häuslichen Tätigkeiten und die Tätigkeiten an der Hochschule ge- 
genüber einer klassischen Aufteilung weitgehend vertauscht: zu Hause erfolgt ein 
Studium eines technischen Gebietes und an der Hochschule wird das Gebiet in 
Teamarbeit diskutiert und praktisch erprobt [376]. 


2.1: Nennen Sie bis zu sechs Anforderungen an Spezifikations- und Modellierungs- 
sprachen für eingebettete Systeme! 
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2.2: Warum könnte es bei der Ausführung unserer Spezifikation zu Verklemmungen 
(engl. Deadlocks) kommen? 


2.3: Was ist ein Berechnungsmodell (engl. Model of Computation (MoC))? 
2.4: Was ist ein Job und was unterscheidet ihn von einer Task? 
2.5: Welche beiden Schlüsseltechniken gibt es für die Kommunikation in Rechnern? 


2.6: Welche Techniken können benutzt werden, um erste Ideen für ein zu entwerfen- 
des System zu erfassen? 


2.7: Simulieren Sie den Zugverkehr zwischen Paris, Brüssel, Amsterdam und Köln 
mit der levi Simulationssoftware [498]! Modifizieren Sie die vorhandenen Beispiele 
so, dass zwischen je zwei Bahnhöfen immer zwei Gleise existieren und zeigen Sie 
einen beliebigen Ablaufplan (engl. Schedule) für zehn Züge! 


2.8: Laden Sie die OpenModelica™ Simulations-Software herunter. Entwickeln Sie 
ein Simulationsmodell für Newton’s cradle (siehe z.B. https://en.wikipedia.org/wiki/ 
Newton%27s_cradle). 


2.9: Modifizieren Sie den Anrufbeantworter aus Beispiel 2.8 so, dass der Eigentümer 
jederzeit während des Abspielens der Ansage oder des Aufnehmens des Anrufers 
den Anruf entgegennehmen kann. 


2.10: Modellieren Sie Ihre täglichen Aktivitäten mit einem zeitbehafteten Automa- 
ten! Stunden sollen einer Variablen h entsprechen, Tage einer Variablen d, wobei 
d = 1 der Montag sein soll und d = 7 der Sonntag. 

An einem Wochenende verlassen Sie den schlafenden Zustand zwischen h = 10 
und h = 11, verbringen 1-2 Stunden mit der Vorbereitung des Tages, bleiben bei 
einem Freund bis zu einer Zeit zwischen h = 20 und h = 21, gehen nach Hause und 
schlafen zwischen h = 22 und h = 23 ein. In der Woche (d e [1..5]) wachen Sie 
zwischen h = 7 und h = 8 auf, verbringen 1-2 Stunden mit der Vorbereitung des 
Tages, studieren bis zu einer Zeit zwischen h = 20 und h = 21, gehen nach Hause 
und schlafen zwischen h = 22 und h = 23 ein. d muss am Ende eines Tages erhöht 
werden. 


2.11: Gegeben sei das StateCharts-Modell von Abb. 2.77 (links). Weiterhin sei 
folgende Sequenz von Eingaben gegeben: b c fh g he abc. Markieren Sie im 
Diagramm von Abb. 2.77 (rechts) alle Zustände, in denen sich das StateCharts- 
Modell befindet, nachdem die angegebene Eingabe anliegt! H kennzeichnet hier den 
History-Mechanismus. 


2.12: Sind StateCharts unter Verwendung der StateMate-Semantik deterministisch? 
Erklären Sie Ihre Antwort! 


2.13: Ist die Sprache SDL deterministisch? Erklären Sie die Antwort! 
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(Reset) v 
b 


Abb. 2.77 StateCharts-Beispiel: links: graphisches Modell; rechts: Tabelle der Zustände 


2.14: Stellen Sie sich vor, dass Sie die Besucherströme im hypothetischen Museum of 
Fine Future Information Nuggets (MUFFIN) modellieren wollen. Das Museum hat 
drei Ausstellungshallen. Vor jeder Halle befindet sich Platz für eine Warteschlange, 
von dem aus man die jeweilige Halle betreten kann. Hallenausgänge führen zu den 
drei Warteschlangen. Besucher können nach dem Verlassen einer Halle eine beliebige 
Halle als ihre nächste aussuchen. Nehmen Sie an, dass jede Halle als ein Prozess 
beschrieben werden kann. Die Zeit, die ein Besucher in einer Halle verbringt, ist 
zufällig. Wir betrachten den stabilen Zustand, in dem kein Besucher das Museum 
betritt oder verlässt. Modellieren Sie das Museum in SDL! Nutzen Sie explizite 
Prozesse und FIFO-Schlangen. 


2.15: Laden Sie die levi-Software für KPNs [496] und entwickeln Sie ein verteiltes 
KPN-Modell zur Berechnung von Fibonacci-Zahlen. Das Modell darf nicht nur aus 
einem einzigen Knoten bestehen. 


2.16: Welche drei Arten von Petrinetzen wurden in diesem Buch beschrieben? 


2.17: Eine Art von Petrinetzen ermöglicht die Verwendung mehrerer, nicht unter- 
scheidbarer Marken pro Position. Welche Komponenten werden in einem mathema- 
tischen Modell solcher Netze verwendet? Hinweis: N=(P, .......... ) 


2.18: Zeichnen Sie das folgende C/E-System: 


e Netz: N =(C,E,F) 

e Bedingungen: C = {c1, C2, C3, C4}, 

« Ereignisse: E = {e1,€2,€3}, 

e Relation: F = {(c1, e1), (c1, 2), (e1, c2), (e1, c3), (e2, c2), (€2, €3), (€2, ca), (C2, €3), 
(c3, e3), (ca, €3), (e3, c1), (e3, c4)} 

Was ist die Vorbedingung von e3, was ist die Nachbedingung von e1? Ist N einfach 

und rein? Wenn es das nicht ist: welche Kante(n) muss man entfernen, damit N ein 

reines Netz wird? Geben Sie eine kurze Begründung Ihrer Aussage an! 


2.19: Skizzieren Sie ein kompaktes Modell des Problems der dinierenden Philoso- 
phen! 


138 2 Spezifikation und Modellierung 


2.20: Die CSA-Theorie beschreibt 2, 3 und 4 Stärken von Logik, die 4, 7 und 
10 Logikwerten entsprechen. Wie viele Stärken und Werte werden in IEEE 1164 
verwendet? Erstellen Sie ein Diagramm, das die Teilordnung der Werte aus IEEE 
1164 zeigt! Welche der Werte aus IEEE 1164 sind in dem Diagramm nicht in der 
Teilordnung enthalten, was bedeuten diese Werte? 


2.21: Gegeben sei ein Bus wie in Abb. 2.78. Welche der Werte aus IEEE 1164 liegen 


: VDD 7 
1 
f & PU1 PU2 & f2 
B 
ena1-+ = t-ena2 
ce & PD1 PD2 & = 
fi f2 
Masse 


Abb. 2.78 Von Tri-State-Ausgängen getriebener Bus 


auf dem Bus an, wenn beide „enable”-Eingänge auf '' liegen (enal = ena2 ='0')? 
Welche der Werte aus IEEE 1164 liegen auf dem Bus an, wenn enal='0', ena2='1' 
und f2='1'? 


2.22: Welche der folgenden Schaltungen kann mit IEEE 1164 modelliert werden: 
komplementäre CMOS-Ausgänge, Ausgänge mit Verarmungstransistor (engl. de- 
pletion transistor), Tristate-Ausgänge, Vorladen von Bussen (wenn ebenfalls Verar- 
mungstransistoren verwendet werden)? 


2.23: Welche der folgenden Sprachen verwenden asynchronen Nachrichtenaus- 
tausch: StateCharts, SDL, VHDL, CSP, Petrinetze, MPI? 


2.24: Welche der folgenden Sprachen verwenden einen Broadcast-Mechanismus zur 
Aktualisierung von Variablen: StateCharts, SDL, Petrinetze? 


2.25: Welche der folgenden Diagrammarten werden von UML unterstützt: Sequenz- 
diagramme, Y-Diagramme, Anwendungsfälle, Aktivitätsdiagramme, Schaltpläne? 


2.26: Tragen Sie in der nachfolgenden Tabelle Berechnungsmodelle der Komponen- 
ten und Kommunikationsmodelle in der linken Spalte ein. Anschließend tragen Sie 
bitte so viele UML-Diagramme wie möglich im Rest der Tabelle ein. 
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Kapitel 3 A 
Hardware eingebetteter Systeme en 


In diesem Kapitel werden das Interface zwischen der physischen Umgebung und 
der Informationsverarbeitung (das Cyphy-Interface) sowie Hardware für die Ver- 
arbeitung, die Speicherung und die Kommunikation von Informationen vorgestellt. 
Die Notwendigkeit der Betrachtung des CyPhy-Interfaces ergibt sich dabei durch die 
Einbettung in ein CPS. Die übrige Hardware muss hier betrachtet werden, weil u.a. 
die erreichte Performanz, das Zeitverhalten, der Speicherbedarf, die Stromaufnahme 
und die Sicherheit von der eingesetzten Hardware abhängig sind. 

Im Kontext des CyPhy-Interfaces werden in diesem Kapitel Schaltungen zur 
Zeit- und Wertediskretisierung sowie zu deren Umkehrung vorgestellt. Auch gehen 
wir auf das Abtasttheorem und seine Folgewirkungen ein. Zur Vorstellung der In- 
formationsverarbeitung dienen v.a. verschiedene Klassen von effizienzoptimierter 
Hardware, insbesondere digitale Signalprozessoren (DSPs), Graphik-Prozessoren 
(GPU), Mehrkern-Systeme sowie programmierbare Logikschaltungen (FPGAs). Im 
Rahmen der Speicherung gehen wir auf Komponenten der Speicherhierarchie in 
einer für eingebettete Systeme angepassten Form ein. Zusätzlich bewerten wir Kom- 
munikationstechnik im Hinblick auf ihre Eignung bei eingebetteten Systemen. 

Zur Realisierung elektronischer Informationsverarbeitung wird elektrische Ener- 
gie benötigt. Daher enthält das Kapitel einen Abschnitt über die Erzeugung, die 
Speicherung und die effiziente Nutzung der Energie in eingebetteten Systemen, 
einschließlich Batterie- und Verbrauchsmodellen. Das Kapitel schließt mit einer 
Übersicht über die Herausforderungen zur hardwaremäßigen Gewährleistung der 
Datensicherheit. 


3.1 Einleitung 


Vielfach werden Entwürfe für Hardware-Komponenten wiederverwendet. Die um- 
fangreiche Wiederverwendung verfügbarer Hard- und Softwarekomponenten ist die 
Grundlage der plattformbasierten Entwurfsmethode (siehe Seite 322). Dieser An- 
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forderung entsprechend und aufgrund des Entwurfsflusses in Abb. 3.1 beschreiben 
wir nun einige wichtige Grundlagen der Hardware eingebetteter Systeme. 


N N 
Spezifikation Entwurfsdatenbank Entwurf 
a 
D 
= 1 | 
Be Abbildung von Test 
g 2 HW-Komponenten Anwendungen 
c= 
= Optimierung 

Systemsoftware = 
-e (RTOS, ...) Bewertung & Validierung 


Abb. 3.1 Vereinfachter Entwurfsfluss 


Die Hardware eingebetteter Systeme ist weit weniger standardisiert als jene von 
PCs. Die große Vielfalt von eingebetteter Systemhardware macht es unmöglich, 
einen umfassenden Überblick über alle Arten von Hardwarekomponenten zu geben. 
Wir versuchen dennoch, einen Überblick über einige wichtige Komponenten zu ge- 
ben, die in den meisten Systemen vorhanden sind. In vielen cyber-physikalischen 
Systemen, insbesondere in Regelungssystemen, wird die Hardware in einer Schleife 
verwendet (siehe Abb. 3.2). Informationen über die physische Umgebung werden 


A/D-Wandler + |__.,|Informations-|>| Anzeige = Energiequelle 
Sample-and-Hold verarbeting, j=] D/A-Wandler < Energiespeicher 
j Pulsbreiten- 
(physische) modulation ee ne 
Sensoren I Ume ebung „| Ableitung von 
\ Aktuatoren Wärme _ _ _ 


Abb. 3.2 Hardwareschleife 


in dieser Schleife über Sensoren bereitgestellt. Sensoren erzeugen normalerweise 
kontinuierliche Folgen von Analogwerten. In diesem Buch beschränken wir uns auf 
Informationsverarbeitung, in der digitale Computer diskrete Wertefolgen verarbei- 
ten. Die dafür erforderlichen Umwandlungen werden mit Hilfe zweier Arten von 
Schaltungen vorgenommen: Abtast- und Halteschaltungen (engl. sample-and-hold 
circuits) und Analog-Digital (A/D)-Wandler. Nach einer solchen Umwandlung kön- 
nen die Informationen digital verarbeitet werden. Die erzeugten Ergebnisse können 
dann angezeigt und weiterverwendet werden, um die physische Umgebung durch 
Aktuatoren zu beeinflussen. Da die meisten Aktuatoren analog arbeiten, wird hier 
auch eine Wandlung von digitalen in analoge Signale benötigt. Diese Wandlung 
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kann entweder direkt durch Digital-Analog-Wandler (DACs) oder indirekt über eine 
Pulsbreitenmodulation erfolgen. 

Für die vorherrschende elektronische Datenverarbeitung benötigen wir elektri- 
sche Energie. Hierfür wird eine Energiequelle benötigt. Sofern unsere Energiequelle 
nicht permanent Energie bereitstellt, wird ein Energiespeicher benötigt, beispiels- 
weise in Form aufladbarer Batterien oder Kondensatoren. Während des Betriebs 
wird ein großer Teil der elektrischen Energie in Wärme- oder thermische Energie 
(Hitze) gewandelt werden. Es kann erforderlich sein, die Wärme abzuführen, z.B. 
über Kühlkörper oder Lüfter. 

Offenbar ist das Modell in Abb. 3.2 für Regelungsanwendungen geeignet. Für 
andere Arten von Anwendungen kann es als eine erste Näherung genutzt werden. Im 
Folgenden beschreiben wir wichtige Hardwarekomponenten cyber-physikalischer 
Systeme entsprechend der Schleifenstruktur von Abb. 3.2. 


3.2 Eingabe - Schnittstelle zwischen physischer und Cyber-Welt 
3.2.1 Sensoren 


Sensoren sind wesentlicher Teil des CyPhy-Interfaces. Sensoren können für fast jede 
existierende physikalische Größe entworfen werden. So gibt es z.B. Sensoren für 
Masse, Geschwindigkeit, Beschleunigung, elektrischen Strom, Spannung, Tempera- 
tur usw. Beim Bau von Sensoren kann dabei eine große Vielfalt von physikalischen 
Effekten ausgenutzt werden [151]. Dazu zählen das Induktionsgesetz (Erzeugung 
von Spannungen in einem elektrischen Feld) und photoelektrische Effekte. Zudem 
existieren auch Sensoren für chemische Substanzen [152]. 

In den vergangenen Jahren wurde eine große Anzahl an Sensorarten entwickelt. 
Ein großer Teil der Fortschritte beim Entwurf intelligenter Systeme ist der modernen 
Sensortechnologie zu verdanken. Die Verfügbarkeit von Sensoren ermöglichte den 
Entwurf von Sensornetzwerken, einem Schlüsselelement des Internets der Dinge 
(siehe beispielsweise Tiwari [542]). Es ist unmöglich, diese Teilmenge der Tech- 
nologie cyber-physikalischer Systeme umfassend zu beschreiben. Wir stellen daher 
hier nur einige typische Beispiele dar: 


e Beschleunigungssensoren: Abb. 3.3 zeigt einen kleinen Sensor, der mit Hilfe 
der Mikrosystemtechnologie gefertigt wurde. In seiner Mitte enthält dieser Sensor 
eine kleine Masse. Wenn er beschleunigt wird, entfernt sich die Masse von ihrer 
Ursprungslage und verändert dabei den Widerstand der kleinen Drähte, die mit 
der Masse verbunden sind. 

Beschleunigungssensoren sind u.a. in den leistungsfähigen sogenannten inertia- 
len Messeinheiten (engl. Inertial Measurement Units IMUs)) enthalten (siehe 
z.B. Siciliano et al. [487], Abschnitt 20.4). Sie enthalten Kreisel und Beschleu- 
nigungssensoren und können bis zu sechs Freiheitsgrade messen, darunter die 
aktuelle Position (x, y, und z) wie auch die Orientierung (Roll-, Nick- und Gier- 
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Abb. 3.3 Beschleunigungssensor 

(zur Verfügung gestellt von S. Biitt- 
genbach, IMT, TU Braunschweig), ©TU 
Braunschweig 


winkel) [580]. Sie sind in Robotern, Flugzeugen, Autos und anderen Produkten 
zum Zweck der Trägheitsnavigation enthalten. 

e Bildsensoren: Es gibt zwei unterschiedliche Arten von Bildsensoren: Ladungs- 
transportspeicher (engl. Charge-Coupled Devices (CCDs)) und CMOS-Senso- 
ren. Beide verwenden gitterförmig angeordnete Lichtsensoren. Die Architek- 
tur von CMOS-Sensoren ähnelt der normaler Speicherbausteine: einzelne Pixel 
können beliebig adressiert und ausgelesen werden. CMOS-Sensoren verwenden 
dabei die Standard-CMOS-Technologie für integrierte Schaltungen. Damit lassen 
sich Sensoren und Logikschaltungen auf einem Chip integrieren. Dies ermöglicht 
„intelligente” Sensoren, bei denen Bildverarbeitungsschritte direkt auf dem Sen- 
sorchip ausgeführt werden können. CMOS-Sensoren benötigen nur eine einzige 
Standard-Versorgungsspannung und sind leicht in das übrige System zu integrie- 
ren. Aus diesem Grund sind CMOS-Sensoren preisgünstig. 

Im Gegensatz dazu ist die CCD-Technologie auf optische Anwendungen opti- 
miert. Hier müssen Ladungen von einem Pixel zum nächsten übertragen werden, 
bis sie schließlich am Rand des Sensorgitters ausgelesen werden können. Dieser 
sequentielle Ladungstransfer ist auch der Namensgeber der CCDs. Die Anbindung 
von CCD-Sensoren ist vergleichsweise aufwendig. 

Die Auswahl des geeignetsten Bildsensors ist allerdings nicht so einfach. In den 
letzten Jahren wurde die Bildqualität von CMOS-Sensoren deutlich gesteigert und 
die qualitative Überlegenheit von CCDs ist in Frage zu stellen. Damit sind sowohl 
CCD- wie auch CMOS-Sensoren dazu in der Lage, eine gute Bildqualität zu 
liefern. Aufgrund ihrer höheren Lesegeschwindigkeit sind CMOS-Sensoren für 
Kameras mit elektronischem Sucher und Kameras mit Videoaufnahmemöglich- 
keit vorzuziehen [405]. Für preisgünstige Geräte wie auch für intelligente Senso- 
ren werden CMOS-Sensoren ebenfalls bevorzugt eingesetzt. Viele Anwendungs- 
bereiche für CCD-Sensoren sind verschwunden, aber für die wissenschaftliche 
Bildgewinnung (beispielsweise in Teleskopen) finden sie gegenwärtig weiterhin 
Anwendung. 

e Biometrische Sensoren: Höhere Sicherheitsstandards haben zu einem verstärk- 
ten Interesse an Authentisierung geführt. Durch die Beschränkungen passwort- 
basierter Sicherheitsmethoden (z.B. durch gestohlene oder verlorene Passwörter) 
hat das Interesse an Smartcards, biometrischen Sensoren und biomedizinischer 
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Authentisierung deutlich zugenommen. Bei biometrischer Authentisierung wird 
zu erkennen versucht, ob eine bestimmte Person tatsächlich diejenige Person 
ist, als die sie sich ausgibt. Biometrische Authentisierungsmethoden sind z.B. 
Iris-Scans, Fingerabdrucksensoren und Gesichtserkennung. Falsche positive wie 
auch falsche negative Erkennungsvorgänge sind ein inhärentes Problem der bio- 
metrischen Authentisierung (siehe Definitionen auf Seite 281). Im Gegensatz zur 
passwortbasierten Authentisierung sind hier exakte Übereinstimmungen nicht 
möglich. 

e Künstliche Augen: Projekte, die künstliche Augen entwickeln, haben nennens- 
werte Beachtung gefunden. Einige dieser Projekte versuchen, das Auge zu erset- 
zen. Andere Projekte versuchen, ein Sehen auf indirekten Wegen zu ermöglichen. 
Das Dobelle-Institut experimentierte beispielsweise mit einer kleinen Kamera, die 
mit einem Rechner verbunden war, der elektrische Impulse über einen direkten 
Kontakt an das Gehirn sandte [532]. In neueren Projekten wurde die Übersetzung 
von Bildern in Toninformationen bevorzugt. Offensichtlich ist diese Methode weit 
weniger invasiv. 

e RFID-Technik: Die RFID-Technik (engl. Radio Frequency Identification Tech- 
nology) basiert auf der Antwort eines Tags auf bestimmte Funksignale [227]. 
Das Tag besteht aus einer integrierten Schaltung und einer Antenne. Es stellt 
einem RFID-Leser seine eindeutige Identifikation zur Verfügung. Die maximal 
mögliche Entfernung zwischen Tag und Leser hängt dabei von der Art des Tags 
ab. Diese Technologie lässt sich überall da einsetzen, wo Objekte, Tiere oder 
Personen identifiziert werden sollen. Sie ist eine Schlüsseltechnologie für das 
Internet der Dinge. 

e Fahrzeugsensoren: Heutige Autos verfügen über eine große Anzahl von Senso- 
ren, welche das Fahren unterstützen sollen, wie beispielsweise Regensensoren, 
Reifensensoren, Abstandssensoren, Motorkontrollsensoren, usw. 

e Andere Sensoren: Weiter gibt es Feuchtigkeits-, Gas- und andere Sensoren. 


Möglicherweise muss Maschinelles Lernen [205, 188, 559, 453] genutzt werden, 
um sinnvolle Informationen aus gestörten Sensorwerten abzuleiten. 

Sensoren erzeugen Signale. Dabei kann der Begriff „Signal” mathematisch wie 
folgt definiert werden: 


Definition 3.1: Ein Signal o ist eine Abbildung von einem Zeitbereich Dr auf einen 
Wertebereich Dy: 
© : Dr > Dy 


Signale können über einem kontinuierlichen oder einem diskreten Zeitbereich sowie 
über einem kontinuierlichen oder einem diskreten Wertebereich definiert sein. 
3.2.2 Zeitdiskretisierung: Sample-and-hold-Schaltungen 


Alle bekannten digitalen Computer arbeiten mit einem diskreten Zeitbereich Dr. 
Damit können sie diskrete Folgen oder Ströme (engl. streams) von Werten ver- 
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arbeiten. In einem kontinuierlichen Zeitbereich vorliegende Werte miissen daher in 
Werte über einem diskreten Zeitbereich konvertiert werden. Dies ist die Aufgabe von 
Sample-and-hold-Schaltungen. Diese sind ebenfalls wesentlicher Teil des CyPhy- 
Interfaces. Abb. 3.4 (links) zeigt eine einfache Sample-and-hold-Schaltung. Diese 


e(t) — h(t) 


Abb. 3.4 Diskretisierung der Zeit: links: Schaltung; rechts: Signale 


Schaltung besteht nur aus einem getakteten Transistor und einem Kondensator. Der 
Transistor arbeitet als Schalter. Wenn der Schalter durch das Taktsignal geschlossen 
wird, wird der Kondensator aufgeladen, sodass seine Spannung h(t) praktisch der 
Eingangsspannung e(t) entspricht. Nachdem der Schalter wieder geöffnet wurde, 
liegt diese Spannung so gut wie unverändert an, bis der Schalter wieder geschlossen 
wird. Jeder der im Kondensator gespeicherten Werte kann als ein Element einer 
diskreten Folge von Werten A(t) angesehen werden, die aus einer kontinuierlichen 
Funktion e(t) erzeugt wurden (siehe Abb. 3.4 (rechts)). Wenn wir nun e(t) zu den 
Zeitpunkten {r,} abtasten, ist h(t) nur zu diesen Zeitpunkten definiert. 

Eine ideale Sample-and-hold-Schaltung könnte die Spannung am Kondensator 
in einer beliebig kurzen Zeitspanne ändern. Damit könnte die Eingangsspannung 
zu einem beliebigen Zeitpunkt auf den Kondensator übertragen werden und jedes 
Element der diskreten Folge entspräche der Eingangsspannung zu einem genau be- 
stimmten Zeitpunkt. In der Praxis muss der Transistor aber für eine kurze Zeitspanne 
geschlossen bleiben, um den Kondensator wirklich laden oder entladen zu können. 
Während dieser Zeitspanne nähert sich die Kondensatorspannung wie bei einer üb- 
lichen Kondensatoraufladung der Eingangsspannung an. 


3.2.3 Fourier-Approximation von Signalen 


Können wir aus dem abgetasteten Signal h(t) das ursprüngliche Signal e(t) rekon- 
struieren? Hier möchten wir uns darauf beziehen, dass beliebige Signale durch die 
Summe von (möglicherweise phasenverschobenen) Sinusfunktionen unterschiedli- 
cher Frequenzen approximiert werden können (Fourier-Approximation)!. 


! Die Darstellung in diesem Buch geht davon aus, dass eine umfassende Vorstellung der Fourier- 
Approximationstheorie nicht im Rahmen einer Vorlesung über eingebettete Systeme erfolgen kann. 
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Beispiel 3.1: Die Abbildungen 3.5 und 3.6 zeigen, dass selbst ein Rechtecksignal 
durch Sinussignale mit steigenden Frequenzen angenähert werden kann. Gleichung 
(3.1) ist die Basis der entsprechenden Approximation [440]. 


K 


4. Inkt 
k=1,35557 A 


In dieser Gleichung ist T die Periode und die Approximation wird mit steigen- 
dem K genauer. Abb. 3.5 und Abb. 3.6 visualisieren Gleichung (3.1). Der größe- 
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Abb. 3.5 Approximation eines Rechtecksignals durch Sinussignale für K=1 (links) und K=3 
(rechts) 
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Abb. 3.6 Approximation eines Rechtecksignals durch Sinussignale fiir K=7 (links) and K=11 
(rechts) 


re Unterschied zwischen dem Rechtecksignal und seinen Approximationen an der 
Sprungstelle (sichtbar v.a. fiir K=11) heißt Gibbs-Phänomen [440]. V 


Daher wird nur die Bedeutung der Theorie anhand einiger Beispiele erklärt. Es wäre für Studierende 
vorteilhaft, die Theorie hinter diesen Beispielen zu kennen (siehe z.B. http://www.dspguide.com). 
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Definition 3.2: Eine signalverarbeitende Transformation Tr wird als linear bezeich- 
net, wenn fiir die Signale e;(t) und e2(t) gilt: 


Tr(eı + e2) = Tr(eı) + Tr(e2) (3.2) 


Im Folgenden betrachten wir nur lineare Systeme. Um die oben gestellte Frage 
zu beantworten, betrachten wie die Auswirkung der Abtastung auf jedes einzelne 
Sinussignal. 


Beispiel 3.2: Nehmen Sie an, unser Eingangssignal entspräche einer der beiden 
Funktionen e3 oder e4: 
Int Int 
e3(t) = sin ©) +0.5 sin (3.3) 
Int Int Int 
ea(t) = sin E) +0.5 sin) +0.5 sin(—) (3.4) 


Die in diesen Funktionen verwendeten Sinussignale haben Perioden von T = 8,4 
und 1 (dies ist leicht zu sehen, wenn man diese Sinussignale mit den Funktionen aus 
Gleichung (3.1) vergleicht). Eine graphische Darstellung dieser Funktionen findet 
sich in Abb. 3.7. 
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Abb. 3.7 Visualisierung der Funktionen e3(t) (blau) und e4(t) (rot) 


Wir wollen diese Signale nun zu ganzzahligen Zeitpunkten abtasten. Zufalliger- 
weise haben beide Signale dann jedes Mal, wenn sie abgetastet werden, denselben 
Wert. Es ist offenbar nicht möglich, zwischen e3(t) und e4(t) zu unterscheiden, wenn 
wir Werte zu den gezeigten Zeitpunkten abtasten und nur dieses abgetastete Signal 
verfiigbar ist. V 
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Allgemein können wir anhand abgetasteter Signale nicht zwischen einem langsamen 
Signal e3(t) und einem sich schneller ändernden Signal e4(t) unterscheiden, wenn 
e3(t) und e4(t) zu den Abtastzeitpunkten identisch sind. Diese Tatsache, dass zwei 
oder mehr Ausgangssignale nach der Abtastung dieselbe Darstellung besitzen, be- 
zeichnet man als Aliasing. Wir tasten e4(t) nicht oft genug ab, um z.B. festzustellen, 
dass Steigungsänderungen zwischen den ganzzahligen Abtastzeitpunkten auftreten. 
Aus diesem Gegenbeispiel können wir folgern, dass die Rekonstruktion des ur- 
sprünglichen Signals nicht machbar ist, solange wir keine zusätzlichen Infor- 
mationen über die in dem Signal vorhandenen Frequenzen oder Wellenformen 
besitzen. 

Wie häufig müssen wir nun Signale abtasten, um zwischen zwei unterschiedlichen 
Sinuswellen unterscheiden zu können? Wir nehmen an, dass wir das Eingangssignal 
in konstanten Zeitabständen abtasten, sodass 7, die Abtastperiode ist: 


Vs: T; = ts41 — ts (3.5) 
Sei 
fs = (3.6) 
e= T, . 


die Abtastrate oder Abtastfrequenz. Gemäß Abtasttheorie gilt [440]: 


Theorem 3.1 (Abtasttheorem): Für die o.a. Definition kann Aliasing vermieden 
werden, wenn Folgendes gilt: 


T; 
T; < = mit Ty : Periode des „schnellsten” Sinussignals bzw. (3.7) 


fs > 2fn mit fy : Frequenz des schnellsten Sinussignals (3.8) 
Definition 3.3: fy wird Nyquist-Frequenz genannt, fs ist die Abtastrate. 


Die Bedingung in Gleichung (3.8) wird Abtastkriterium oder manchmal auch 
Nyquistsches Abtastkriterium genannt. 

Die Rekonstruktion von Eingangssignalen e(t) aus diskreten Abtastwerten A(t) 
kann also nur funktionieren, wenn wir sicherstellen, dass höhere Frequenzkomponen- 
ten, wie die in e4(t) vorkommende, entfernt wurden. Dies ist die Aufgabe von Anti- 
aliasing-Filtern. Anti-aliasing-Filter werden vor die Sample-and-hold-Schaltung ge- 
schaltet (siehe Abb. 3.8). 


e(t) 
g(t) 


Anti- Sample- | 5 
aliasing & hold 


| | 


Abb. 3.8 Der Sample-and-hold-Schaltung vorgeschaltetes Anti-aliasing 
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Abb. 3.9 zeigt den Amplitudengang, d.h. das Verhältnis der Amplituden zwi- 
schen dem Ausgangs- und dem Eingangssignal als Funktion der Filterfrequenz. 


Amplitudengang 


! idealer Filter 


Abb. 3.9 Amplitudengänge idealer und realisierbarer Anti-aliasing-Filter (Tiefpassfilter) 


Idealerweise wiirde solch ein Filter alle Frequenzen ab der halben Abtastfrequenz 
aufwärts entfernen und alle anderen Frequenzkomponenten unverändert lassen. Da- 
mit ließe sich das Signal e4(t) in das Signal e3(t) umwandeln. 

In der Praxis existieren solche idealen Filter jedoch nicht?. Reale Filter dämpfen 
bereits Frequenzen unterhalb von f, /2 und entfernen nicht alle Frequenzen oberhalb 
von fs/2 (siehe Abb. 3.9). Gedämpfte hochfrequente Anteile sind daher auch nach 
der Filterung noch vorhanden. Für Frequenzen unterhalb von f,/2 kann auch Über- 
schwingen (engl. overshooting) auftreten, d.h. es existieren Frequenzen, für die das 
Eingangssignal verstärkt wird. 

Der Entwurf guter Anti-Aliasing-Filter erfordert Spezialkenntnisse. Diese Kennt- 
nisse werden beispielsweise beim Entwurf hochwertiger Audiogeräte eingesetzt, der 
üblicherweise Hörproben erfordert. Viele der empfundenen Unterschiede zwischen 
verschiedenen hochwertigen Audiogeräten werden dem Entwurf guter Filter zuge- 
schrieben. 


3.2.4 Wertediskretisierung: A/D-Wandler 


Da wir nur digitale Computer betrachten, müssen wir auch Signale, die Zeit aufeinen 
kontinuierlichen Wertebereich Dy abbilden, durch solche Signale ersetzen, welche 
die Zeit auf einen diskreten Wertebereich Dy, abbilden. Diese Wandlung von analo- 
gen zu digitalen Werten wird von Analog-Digital-Wandlern (A/D-Wandlern) reali- 
siert. Es gibt viele Arten von A/D-Wandlern mit unterschiedlicher Geschwindigkeit 
und Genauigkeit. Typischerweise haben schnelle Wandler eine geringe Genauigkeit 
und genaue Wandler sind langsam. 

In diesem Buch werden wir in den nächsten Unterabschnitten verschiedene 
Wandler-Typen vorstellen. 


? Solche Filter würden voraussetzen, dass man das Signal für eine unbeschränkte Zeit kennt. 
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Flash-A/D-Wandler 


Diese Art von A/D-Wandlern verwendet eine große Anzahl an Komparatoren. Jeder 
Komparator besitzt zwei Eingänge + und -. Wenn die Spannung am Eingang + die 
Spannung am Eingang - übersteigt, entspricht der Ausgang einer logischen '1', 
ansonsten einer logischen '0'°. 

Alle - -Eingänge des A/D-Wandlers sind mit einem Spannungsteiler verbunden. 
Wenn die Eingangsspannung h(t) den Wert Veer übersteigt, erzeugt der oberste 
Komparator in Abb. 3.10 (links) eine '1'. Der an den Ausgängen der Komparatoren 
befindliche Encoder versucht, die höchstwertige '1' zu erkennen und kodiert diesen 
Fall als größtmöglichen Ausgabewert. Der Fall h(t) > V;er sollte normalerweise 
vermieden werden, da V,.r meist nahe der Versorgungsspannung der Schaltung 
liegt und Eingangsspannungen größer als die Versorgungsspannung zu elektrischen 
Problemen führen können. In unserem Fall erzeugen Eingangsspannungen größer als 
V,.r den größten digitalen Wert, solange der Konverter nicht wegen einer zu hohen 
Eingangsspannung ausfällt. 


Vef w 
h(t) 7 
Ers "] ] a 
3 oe Digitale 
q ref im „| Ausgange "79" 
2 Ree 3 w(t) 
4 ref +} Si "g1" 
Lye 
greft "ag" 


R Komparatoren 1 
0 2 Ver V, I 1 


Abb. 3.10 Flash-A/D-Wandler: links: Schaltung; rechts: w als Funktion von h 


Wenn nun der Wert der Eingangsspannung A(t) kleiner als 3 Vref, aber noch 
größer als iVre f ist, erzeugt der oberste Komparator in Abb. 3.10 eine '@', wogegen 
der folgende Komparator immer noch eine '1' signalisiert. Der Encoder wird dies 
als den zweitgrößten Wert darstellen. 

Entsprechend verhält es sich für die Fälle iVre f < h(t) < Vref und 0 < A(t) < 
iVre f» die als drittgrößter bzw. kleinster Wert dargestellt werden. Abb. 3.10 (rechts) 
zeigt das Verhältnis zwischen Eingangsspannungen und erzeugten digitalen Werten. 

Die Ausgänge des Komparators stellen Werte auf eine besondere Art dar. Wenn 
der Ausgang eines bestimmten Komparators den Wert '1' hat, dann sind auch alle 
niederwertigen Ausgänge gleich '1'. Der Encoder übersetzt diese Zahlendarstel- 
lung in die gewohnte Darstellung natürlicher Zahlen. Dieser Encoder ist damit ein 


3 In der Praxis ist der Fall gleicher Spannungen nicht relevant, da das tatsächliche Verhalten für 
sehr kleine Spannungsunterschiede an den beiden Eingängen noch von vielen weiteren Faktoren 
abhängt (wie z.B. der Temperatur und dem Herstellungsprozess). 
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sogenannter „Prioritätsencoder”, der den höchstwertigen Eingang darstellt, der eine 
binäre '1' enthält®. 

Die Schaltung wandelt positive analoge Eingangsspannungen in digitale Werte 
um. Das Konvertieren sowohl positiver wie auch negativer Eingangsspannungen 
und die entsprechende Erzeugung von Zweierkomplementzahlen erfordert einige 
Erweiterungen. 

Flash-A/D-Wandler sind automatisch monoton. Das bedeutet, dass für eine von 
0 bis zum Maximum ansteigende Spannung die entsprechenden Digitalwerte auch 
garantiert ansteigen. Diese Eigenschaft bleibt selbst dann erhalten, wenn der reale 
Widerstandswert vom nominellen abweichen sollte. Allerdings hätte eine solche 
Abweichung einen Einfluss auf die Genauigkeit der Wandlung. 

Leider bildet die Widerstandskette einen elektrisch leitenden Pfad selbst in sol- 
chen Phasen, in denen der Wandler unbenutzt ist. Deshalb ist der Wandler in der 
Regel nicht für stromsparende Schaltungen geeignet. 

Allgemein werden A/D-Wandler durch ihre Auflösung gekennzeichnet. Dieser 
Begriff hat verschiedene miteinander verwandte Bedeutungen [15]. Die Auflösung 
(gemessen in Bits) ist die Anzahl an Bits, die ein A/D-Wandler erzeugt. Beispiels- 
weise werden für viele Audioanwendungen A/D-Wandler mit einer Auflösung von 
16 Bit benötigt. Die Auflösung wird aber auch in Volt angegeben, in diesem Fall 
kennzeichnet sie den Abstand, der zwischen zwei Eingangsspannungen vorhanden 
sein muss, damit die Ausgabe um 1 inkrementiert wird: 


VFSR 
Q= 
n 
mit: Q : Auflösung in Volt pro Schritt, 


(3.9) 


Vrsr : Differenz zwischen größter und kleinster Spannung und 


n : Anzahl der Spannungsintervalle (nicht Anzahl der Bits). 


Beispiel 3.3: Der A/D-Wandler aus Abb. 3.10 besitzt eine Auflösung von 2 Bit oder 
iVre f Volt, wenn wir V,ef als größten Wert annehmen. V 


Der entscheidende Vorteil von Flash-A/D-Wandlern ist ihre Geschwindigkeit. Sie 
benötigen keinerlei Takt. Die Verzögerung zwischen Eingabe und Ausgabe ist gering 
und die Schaltung kann z.B. einfach für Hochgeschwindigkeits-Videoanwendungen 
eingesetzt werden. Der Nachteil ist die Komplexität der Hardware: wir benötigen 
n-1 Komparatoren, um zwischen n Werten unterscheiden zu können. Stellen Sie sich 
vor, diese Schaltung würde verwendet, um digitale Audiosignale für CD-Recorder 
zu erzeugen. Wir würden 2'° — 1 Komparatoren benötigen! Hochauflösende A/D- 
Wandler müssen daher anders konstruiert sein. 


* Solche Encoder sind auch dabei nützlich, die höchstwertige '1' in der Mantisse einer Gleitkom- 
mazahl zu finden. 
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Sukzessive Approximation (Wägeprinzip) 


Hochauflösende Wandler sind mit der sukzessiven Approximation möglich. Die 
Schaltung dafür ist in Abb. 3.11 dargestellt. 


Abb. 3.11 Schaltung, h(t) 4 Steuerlogik 
die sukzessive Appro- - P 3 ; z 
2 canon verwendet Register für sukzessive Approximation 


L digitaler Ausgang 
w(t) 


D/A-Wandlung 


Die zugrunde liegende Idee ist hier die Verwendung von binärer Suche. Zu An- 
fang ist das höchstwertige Ausgangsbit des sukzessiven Approximations- Registers 
auf '1' und alle anderen Bits auf '@' gesetzt. Dieser digitale Wert wird dann in 
eine analoge Spannung gewandelt, die der Hälfte der maximalen Eingangsspannung 
entspricht’. Wenn A(t) größer als der erzeugte analoge Wert ist, wird die '1' im 
höchstwertigen Bit beibehalten, ansonsten wird das Bit auf '@' gesetzt. 

Dieser Vorgang wird für das nächste Bit wiederholt. Es bleibt auf '1', wenn der 
Eingabewert entweder im zweiten oder vierten Viertel des Eingangsspannungsbe- 
reiches liegt. Der Vorgang wird dann für alle übrigen Bits ebenfalls wiederholt. 


Abb. 3.12 zeigt ein Beispiel. Anfangs ist das V 
höchstwertige Bit auf '1' gesetzt. Dieser Wert 
wird beibehalten, da die resultierende Spannung 
V_ kleiner als A(t) ist. Anschließend wird das 
nächste Bit auf '1' gesetzt. Dieses wird zu 'Q' 
zurückgesetzt, da die resultierende Spannung h(t) 
V_ größer als A(t) ist. Daraufhin werden die 
weiteren niederwertigen Bits verglichen. Offen- 
sichtlich muss A(t) während der Umwandlung 
konstant bleiben. Diese Anforderung lässt sich > 
durch die Verwendung der oben beschriebenen Abb. 3.12 Sukzessive Approximation 
Sample-and-hold-Schaltung erfüllen. Das resultierende digitale Signal wird mit w(t) 
bezeichnet. 

Der wesentliche Vorteil der sukzessiven Approximation liegt in ihrer Hardwareef- 
fizienz. Es werden nur [log>(n)] Bits im sukzessiven Approximations-Register sowie 
der D/A-Wandler benötigt, um zwischen n digitalen Werten zu unterscheiden. Der 
Nachteil ist die geringe Geschwindigkeit, da O(/og2(n)) Schritte benötigt werden. 
Diese Wandler sind daher für Anwendungen geeignet, die eine hohe Auflösung bei 
mittleren Geschwindigkeiten benötigen. Beispiele hierfür sind Audioanwendungen. 


1108 1911 


1908 1918 


rtititititititits, 


5 Die Wandlung von digitalen zu analogen Werten (D/A-Wandlung) kann sehr effizient implemen- 
tiert werden und ist sehr schnell (siehe Seite 197). 
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Fließband-A/D-Wandler 


Diese Wandler bestehen aus einer Folge von Stufen, von denen jede für die Wand- 
lung von einigen wenigen Bits zuständig ist (siehe Abb. 3.13). Jede Stufe leitet die 


Vin | Stufel |Vres? | Stufe2 | Vres2 Stufe k 
=|B Bits “|B Bits | IB, Bits 
1 2 k 
MSB ... 7a LsB | 
l l 
Ausrichtung und Kombination der Daten 


Digitaler Ausgang \ B, +B at .. + By) Bits 


Abb. 3.13 Fließband-A/D-Wandler [292] 


Differenz (den nicht gewandelten Rest) zwischen dem Eingangswert und der analo- 
gen Darstellung des erzeugten Digitalwertes an die nächste Stufe (sofern vorhanden) 
weiter. Beispielsweise könnte jede Stufe ein einzelnes Bit wandeln und die entspre- 
chende Spannung von der Eingangsspannung abziehen. Die resultierende Spannung 
würde typischerweise wieder mit einem Faktor von zwei skaliert werden (um kleine 
Spannungen zu vermeiden) und an die nächste Stufe weitergeleitet werden. Üblicher- 
weise enthält jede Stufe einen Flash-A/D-Wandler für einige wenige Bits und einen 
D/A-Wandler zur Berechnung der zu subtrahierenden Spannung. Die resultierenden 
Digitalwerte müssen zeitlich korrekt zugeordnet werden. Der Hardwareaufwand für 
diese Wandlung wächst linear mit der Anzahl der Bits. Es kann ein guter Durchsatz 
erzielt werden, aber die Latenzzeit ist größer als für Flash-A/D-Wandler. 


Andere Wandler 


Integrierende Wandler benutzen (mindestens) zwei Phasen für die Messung. Wäh- 
rend der ersten Phase der Länge tı wird das Integral der Eingangsspannung über 
der Zeit berechnet®. Für konstante Eingangsspannungen ist der resultierende Wert 
Vout proportional zur Eingangsspannung (Vout ~ Vin * t1). Während der zweiten 
Phase wird dieser Wert mit einer konstanten Rate reduziert und es wird mit einem 
Zähler gemessen, wie lange es dauert, bis der Wert 0 erreicht wird. Der erreichte 
Zählerstand ist proportional zur Eingangsspannung. Ein Vorteil der Schaltung liegt 
darin, dass ein ggf. vorhandenes Eingangsrauschen während der Integrationsphase 
mit hoher Wahrscheinlichkeit herausgemittelt wird. Aufgrund dieser Unterdrückung 


6 Dies kann mit einem Kondensator in der Rückkopplungsschleife eines Operationsverstärkers 
(siehe Seite 429) gemacht werden. 
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von Eingangsrauschen eignet sich dieses Prinzip der Wandlung v.a. für Wandler 
einer hohen Genauigkeit, wie sie z.B. in Multimetern zu finden sind. 

Bei faltenden A/D-Wandlern wird die Eingangsspannung in 2” Segmente auf- 
geteilt [100, 322]. Ein grobgranularer Wandler bestimmt das Segment der jeweils 
vorhandenen Eingangsspannung und bestimmt damit die signifikantesten m Bits. Ein 
feingranularer Wandler bestimmt den Wert innerhalb eines Segments und berechnet 
so die weniger signifikanten Ausgabebits. 

Bei Delta-Sigma A/D-Wandlern werden, wie der Name es vermuten lässt, Si- 
gnaldifferenzen (As) kodiert und aufsummiert (2). Eine Beschreibung dieser Wand- 
ler geht über den Themenkreis dieses Buches hinaus. Interessierte Leser können 
beispielsweise bei Khorramabadi [293] nachschlagen. 


Vergleich von A/D-Wandlern 


Abb. 3.14 bietet einen Überblick über die Beziehungen zwischen der Auflösung und 
der Geschwindigkeit verschiedener Typen von A/D-Wandlern auf der Basis einer 
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Abb. 3.14 Vergleich der Geschwindigkeiten und der Auflösung von A/D-Wandlertypen [557] 


Analyse von Vogels et al. [557]. Danach sind Flash-A/D-Wandler offensichtlich die 
schnellsten, aber sie bieten nur eine begrenzte Auflösung. Fließband-A/D-Wandler 
sind häufig der sukzessiven Approximation überlegen. IEEE TV [437] bietet eine 
weitere Übersicht. 
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Quantisierungsrauschen 


Abb. 3.15 zeigt das Verhalten des Flash-A/D-Wandlers für ein Eingangssignal gemäß 
Gleichung (3.3). Nur das Verhalten für ein positives Eingangssignal ist gezeigt. Die 
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Abb. 3.15 h(t) (blau), w(t) (rot), w(t) — A(t) (schwarz) 


Abbildung enthält die Spannung, die dem bestimmten Digitalwert entspricht, die 
ursprüngliche Spannung und die Differenz zwischen beiden. Offensichtlich rundet 
der Konverter die digitale Darstellung entsprechend der Anzahl der verfügbaren 
Bits ab (d.h. der Digitalwert entspricht immer einer Spannung kleiner oder gleich 
der Eingangsspannung). Dies ist eine Konsequenz aus der Art und Weise, wie der 
Konverter Vergleiche durchführt. Rundende Konverter würden eine Korrektur um 
ein halbes Bit benötigen. Tatsächlich entspricht das Digitalsignal einem Analogwert 
der Summe aus dem Originalsignal und der Differenz w(t) — h(t). Das heißt, es sieht 
so aus, als ob die Differenz zwischen den beiden Signalen auf das Eingangssignal 
aufaddiert wird. Diese Differenz heißt Quantisierungsrauschen: 


Definition 3.4: Sei A(t) ein Analogsignal. Sei w(t) von h(t) durch Quantisierung 
abgeleitet. Die Differenz zwischen beiden heißt Quantisierungsrauschen: 


Quantisierungsrauschen(t) = w(t) — h(t) < Q (3.10) 


Definition 3.5: Das Quantisierungsrauschen lässt sich offensichtlich reduzieren, in- 
dem die Auflösung (in Bit) der A/D-Wandler erhöht wird. Der Einfluss des Quanti- 
sierungsrauschens wird meist in der Definition des Signal-Rausch-Abstands (engl. 
Signal-to-Noise Ratio (SNR)) festgehalten. Der Signal-Rausch-Abstand wird in 
Dezibel gemessen (Zehntel eines Bel, benannt nach Alexander G. Bell): 
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Leistung des Nutzsignals 


SNR (in dB = Dezibel) = 10 * log (3.11) 


Leistung des Rauschsignals 
Spannung des Nutzsignals 


= 20 « log (3.12) 


Spannung des Rauschsignals 


In diesem Fall haben wir ausgenutzt, dass die Energie eines Signals fiir jede beliebige 
Impedanz R gleich dem Quadrat der Spannung ist. Dezibel ist keine physikalische 
Einheit, da der Signal-Rausch-Abstand dimensionslos ist. 

Für jedes Signal h(t) beträgt die Energie des Quantisierungsrauschens « - Q, 
wobei a < 1 von der Wellenform von h(t) abhängt. Wenn h(t) stets exakt durch 
einen digitalen Wert wiedergegeben werden kann, beträgt der Wert a = 0. Wenn 
A(t) andererseits immer „ein wenig” unterhalb des nächsten darstellbaren Wertes 
liegt, kann «œ nahe an 1 liegen. 


Beispiel 3.4: Der Signal-Rausch-Abstand von 16-Bit CD-Audio (mit a ~ 1) liegt 
in der Größenordnung von: 20 x log(2!°) = 96 dB. Für qualitativ hochwertige 24- 
Bit CDs beträgt der Signal-Rausch-Abstand rund 144 dB. Werte von a < 1 und 
Fertigungstoleranzen von A/D-Wandlern können diese Werte allerdings noch beein- 
flussen. Vv 


3.3 Verarbeitungseinheiten 


In diesem Abschnitt betrachten wir das nächste Element in der Regelschleife nach 
Abb. 3.2, nämlich Verarbeitungseinheiten. Für die Datenverarbeitung in eingebette- 
ten Systemen betrachten wir anwendungsspezifische integrierte Schaltkreise (engl. 
Application-Specific Integrated Circuit (ASICs)), rekonfigurierbare Logik und ver- 
schiedene Typen von programmierbaren Prozessoren. Wir starten mit ASICs. 


3.3.1 Anwendungsspezifische integrierte Schaltkreise 


Für Hochleistungsanwendungen und große Stückzahlen kann es sich lohnen, dass 
eine anwendungsspezifische Schaltung entworfen wird. Allgemein sind ASICs sehr 
energieeffizient (siehe Unterabschnitt 3.7.3 auf Seite 211). Allerdings fallen hohe 
Kosten für den Entwurf und die Fertigung solcher Chips an. Die Kosten für einen 
Satz von Masken, mit denen die geometrischen Muster auf den Chip übertragen 
werden, sind mit zunehmender Miniaturisierung stark gestiegen’. 

Allerdings kann man diese Kosten durch die Verwendung weniger fortgeschrit- 
tener Fabrikationstechnologie und durch die Nutzung von Multi-Projekt-Wafern 
(MPW), die mehrere Schaltkreise enthalten, senken. Der Einsatz von ASICs leidet 


7 2017 lagen die durchschnittlichen Kosten gemäß http://anysilicon.com/semiconductor- wafer- 
mask-costs/ für eine fortgeschrittene 28 nm-Technologie bei etwa 1,5M $. 
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unter langer Entwurfsdauer und einem Mangel an Flexibilität: um Entwurfsfehler zu 
korrigieren, wird meist ein neuer Satz Masken und ein erneuter Herstellungslauf be- 
nötigt. Daher sind ASICs nur dann angemessen, wenn spezielle Umstände vorliegen, 
wie beispielsweise der Bedarf an großen Stückzahlen, maximale Energieeffizienz, 
spezielle Spannungs- oder Temperaturbereiche, gemischte Analog-/Digitalschaltun- 
gen oder hohe Sicherheitsanforderungen. Daher behandeln wir den Entwurf von 
ASICs in diesem Buch nicht weiter. 


3.3.2 Prozessoren 


Der Hauptvorteil von Prozessoren ist ihre Flexibilität. Wenn Prozessoren eingesetzt 
werden, kann das gesamte Verhalten eines eingebetteten Systems alleine durch die 
Änderung der darauf laufenden Software verändert werden. Verhaltensänderungen 
können erforderlich sein, um Entwurfsfehler zu korrigieren, das System auf einen 
neuen oder geänderten Standard zu aktualisieren oder um dem existierenden System 
neue Eigenschaften hinzuzufügen. Auf diesen Gründen haben Prozessoren, insbe- 
sondere kommerziell „aus dem Regal” (engl. Commercial Off-The-Shelf (COTS)) 
verfügbare, eine weite Verbreitung gefunden. 

Eingebettete Prozessoren müssen schonend mit Ressourcen umgehen, d.h. wir 
müssen uns darum kümmern, welche Ressourcen zur Ausführung von Anwendungen 
erforderlich sind. Dabei müssen sie aber nicht kompatibel zum Instruktionssatz der in 
PCs oder Servern verwendeten Prozessoren sein. Dadurch kann ihre Architektur von 
diesen Prozessoren abweichen. Die Ressourceneffizienz besitzt eine Vielzahl von 
Aspekten (siehe Seite 14), die als nächstes auszugsweise diskutiert werden sollen. 


Energieeffizienz 


Die Energie E zur Ausführung einer bestimmten Anwendung hängt eng mit der 
(elektrischen) Leistung P(t) als Funktion der Zeit zusammen, denn es gilt Gleichung 
(3.13). 


E= J P(t)dt (3.13) 


Wir nehmen an, dass wir mit einem Entwurf mit einem Leistungsverbrauch von 
Po(t) starten, woraus sich nach einer Ausführungszeit von fo ein Energieverbrauch 


von P 
0 
Eo = T Po(t)dt 
0 


ergibt. Angenommen, ein modifizierter Entwurf führt die Applikation bereits in tı 
Zeiteinheiten aus und benötigt dabei eine Leistung Pı(?). Für diesen ergibt sich ein 
Energieverbrauch von 
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ti 
E; = / P,(t)dt 
0 


Wenn P(t) nicht viel größer ist als Po(t), dann bedeutet die Reduktion der Aus- 
führungszeit auch eine Reduktion des Energieverbrauchs. Allerdings bedeutet eine 
Reduktion der Zeit nicht unbedingt auch eine Reduktion der Energie. Dies ist in 
Abb. 3.16 gezeigt: E kann kleiner sein als Eo, aber auch größer. Deswegen ist es zur 
Minimierung des Energieverbrauchs notwendig, auch diesen explizit als Optimie- 
rungskriterium zu benutzen. Eine Minimierung der Laufzeit kann nicht als Ersatz 
dienen. 


Abb. 3.16 Vergleich von P 


Mehr Leistung, weniger Energie? 
Energien Ep und E; 


Pı(t) = 
i 


Sowohl die Minimierung der Leistung wie auch die der Energie sind wichtig. 
Die Leistung hat einen Einfluss auf die Dimensionierung der Stromversorgung, den 
Entwurf der Spannungsregler, die Dimensionierung der Leitungen und die kurzfris- 
tige Kühlung. Die Minimierung des Energieverbrauchs ist insbesondere für mobile 
Anwendungen wichtig, da die Batterietechnologie nur langsam Fortschritte macht 
und da die Kosten für Energie sehr hoch sein können. Der Energieverbrauch hat auch 
einen Einfluss auf die Erzeugung von CO2, wobei mobile Anwendungen aufgrund 
der begrenzten Batteriekapazitäten in der Regel weniger CO2 produzieren als statio- 
näre Anwendungen. Ein kleiner Energieverbrauch reduziert auch die Kosten für die 
Kühlung und erhöht die Lebensdauer des Systems (weil diese in der Regel mit der 
Temperatur sinkt). 

Als nächstes soll gezeigt werden, dass es für CMOS-Technologie von Vorteil ist, 
schnelle sequentielle Berechnungen durch langsamer ausgeführte parallele Berech- 
nungen zu ersetzen. Dazu betrachten wir zunächst die Leistungsaufnahme P von 
CMOS-Schaltungen. Die sogenannte dynamische Leistungsaufnahme ist die Leis- 
tungsaufnahme, die aufgrund des Schaltens von Transistoren und des Umladens von 
Leitungen entsteht (im Gegensatz zur statischen Leistungsaufnahme, die selbst oh- 
ne Schaltvorgänge entsteht). Die durchschnittliche dynamische Leistungsaufnahme 
Payn von CMOS kann gemäß Gleichung (3.14) modelliert werden [90]: 


Pin =O Cr Via f (3.14) 
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wobei œ die Schaltaktivität, Cz die Ladekapazität, Vig die Versorgungsspannung 

und f die Taktfrequenz darstellt. Dies bedeutet, dass die Leistungsaufnahme von 

CMOS-Prozessoren (mindestens) quadratisch mit der Betriebsspannung anwächst®. 
Die Verzögerung von CMOS-Schaltungen lässt sich annähern als [90] 


Vad 


A = kC, —— 
(Vaa - Vr) 


(3.15) 


Dabei ist k eine Konstante und V; die Schwellenspannung. V, beeinflusst die Ein- 
gangsspannung, die erforderlich ist, um den Transistor einzuschalten. Bei einer 
maximalen Versorgungsspannung von Vy4,max=3,3 Volt könnte V; in der Größen- 
ordnung von 0,8 Volt liegen. Folglich ist die maximale Taktfrequenz eine Funktion 
der Versorgungsspannung. Durch Absenken der Versorgungsspannung nimmt aber 
die Leistung quadratisch ab, wogegen die Laufzeit von Algorithmen nur linear steigt 
(wenn man die Einflüsse des Speichersystems nicht berücksichtigt). 

Dieser Effekt wird ausgenutzt, um den Energieverbrauch durch eine bestimmte 
Menge an Operationen zu reduzieren. Dazu nehmen wir an, dass wir zunächst Ope- 
rationen mit einer Spannung Vgq, einer konstanten Leistung P, einer Taktfrequenz 
f und einer Laufzeit t sequentiell ausführen und dabei eine elektrische Energie 
E = P xt verbrauchen. 

Wir stellen uns nun vor, dass wir dazu übergehen, 6 Operationen parallel aus- 
zuführen. Aufgrund der parallelen Ausführung können wir die Zeit zur Ausführung 
einer Operation jetzt um den Faktor £ strecken. Damit können wir auch die Frequenz 
um denselben Faktor reduzieren und kommen zu einer neuen Taktfrequenz 


,_ f 
f=5 (3.16) 
B 
Dies erlaubt es uns, auch die Spannung auf eine neue Spannung zu reduzieren: 
V, 
Via = T (3.17) 


Damit verringert sich die Leistung pro Operation quadratisch: 
pai 
2 
Da wir 8 Operationen parallel ausführen, gehen wir aus von einer neuen Leistung 
von 


(3.18) 


P 
P' = Bx Po =— (3.19) 
B 
Die neue Ausführungszeit t’ ist aufgrund der Paralelausführung gleich der alten Zeit 
t, d.h. t’ = t. Mithin ergibt sich die neue Energie als 


8 In der Praxis kann der Anstieg noch dariiber liegen. 
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E 
E'=P'st= T (3.20) 


Es ist offenbar energieeffizienter, 8 Operationen parallel (und jede einzelne rela- 
tiv langsam) auszuführen, anstatt sie sequentiell (und jede einzelne Operation relativ 
schnell) auszuführen. Allerdings enthält unsere Rechnung einige Annahmen und 
Näherungen. Auf der einen Seite gibt es Gründe für eine noch größere Energieein- 
sparung. Wenn es uns gelingt, die Leistung konstant zu halten anstatt sie gemäß 
Gleichung (3.19) durch die Parallelausführung zu erhöhen, so würde die Energie 
sogar quadratisch abnehmen. Sie würde ebenfalls stärker als linear abnehmen, wenn 
— wie dies experimentell beobachtet wurde — die Leistung sogar kubisch von der 
Spannung abhängt. Außerdem haben wir ignoriert, dass die Speichergeschwindig- 
keit häufig der begrenzende Faktor ist. Eine höhere Taktrate kann mithin bedeuten, 
dass der Prozessor „mit schnellerem Takt auf den Speicher wartet” und eine geringere 
Taktrate also die Ausführung gar nicht um den Faktor £ verlangsamt. Auf der anderen 
Seite müssen wir 8 Operationen finden, die wir parallel ausführen können. Insgesamt 
können wir festhalten, dass parallele Ausführung ein Mittel zur energieeffizienten 
Berechnung ist, unabhängig von der konkreten Hardwarerealisierung. 

Hardwarearchitekturen müssen in Bezug auf die Energieeffizienz optimiert wer- 
den und wir müssen sicherstellen, dass wir in der Softwareerzeugung keine Effizienz 
verlieren. 

Es gibt eine große Anzahl von Techniken, mit denen die Energieeffizienz von 
Prozessoren gesteigert werden kann. Energieeffizienz sollte dabei auf verschiedenen 
Abstraktionsebenen betrachtet werden, vom Entwurf des Befehlssatzes bis hinab zum 
Entwurf der eigentlichen Chipfertigung [77]. Taktabschaltung (engl. clock gating) 
ist ein Beispiel für eine solche Technik. Die Taktabschaltung wird verwendet, um 
aktuell nicht benötigte Teile eines Prozessors vom Takt zu trennen. So werden 
beispielsweise Hardwareeinheiten für direkten Speicherzugriff (engl. Direct Memory 
Access (DMA)) oder Busbrücken nicht mit Takt versorgt, wenn sie nicht benötigt 
werden. Zudem existieren Ansätze, um den größten Teil eines Prozessors komplett 
taktlos betreiben zu können. Dabei gibt es zwei gegensätzliche Ansätze: global 
asynchrone, aber lokal synchrone Prozessoren (GALS) [263] und global synchrone, 
aber lokal asynchrone (GSLA) [117]. Weitere Informationen über stromsparende 
Entwurfstechniken finden sich in einem Buch von E. Macii [361] sowie in den 
PATMOS-Tagungsbänden (siehe http://www.patmos-conf.org/). 

Auf einer vergleichsweise hohen Abstraktionsebene lassen sich mindestens drei 
Techniken einsetzen: 


« Parallele Ausführung: Aufgrund von Gleichung (3.20) ist die parallele Ausfüh- 
rung ein gutes Mittel, um die Energieeffizienz zu erhöhen. 

e Dynamisches Power Management (DPM): Bei dieser Methode verfügen Pro- 
zessoren zusätzlich zum normalen Betriebszustand über verschiedene weitere 
Energiesparzustände. Jeder dieser Zustände bringt eine unterschiedliche Leis- 
tungsaufnahme mit sich und benötigt unterschiedlich viel Zeit, um den Prozessor 
wieder in den normalen Betriebszustand zu überführen. Abb. 3.17 zeigt die drei 
Zustände des StrongARM SA 1100-Prozessors. 
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Abb. 3.17 DPM-Zustände des 
StrongArm-Prozessors SA1100 [45] 


Der Prozessor ist im run-Zustand voll betriebsbereit. Im idle-Zustand überwacht 
er nur die Interrupt-Eingänge. Im sleep-Zustand wird der Prozessor zurückgesetzt 
und die Stromversorgung des Chips abgeschaltet [593]. Eine separate Stromver- 
sorgung für die Ein/Ausgabeeinheiten liefert Strom für die Energieverwaltungs- 
hardware. Der Prozessor kann durch ein vorher festgelegtes Aufweckereignis 
durch die Energieverwaltung neu gestartet werden. Beachtenswert ist hier der 
große Unterschied im Energieverbrauch zwischen dem sleep-Zustand und den 
anderen Zuständen, ebenso die große Zeitdauer, die benötigt wird, um vom sleep- 
zum run-Zustand umzuschalten. 

e Dynamische Spannungsskalierung: Gleichung (3.14) wird von der sogenann- 
ten dynamischen Spannungsskalierung (engl. Dynamic Voltage Scaling (DVS)) 
ausgenutzt. So verfügte beispielsweise der Crusoe"-Prozessor von Transmeta 
[296] über 32 Spannungsstufen zwischen 1,1 und 1,6 Volt, der Takt konnte in 
33 MHz-Schritten von 200 MHz bis 700 MHz variiert werden. Ein Übergang von 
einer Spannungs-/Frequenzkombination zur nächsten benötigte rund 20 ms. Ent- 
wurfsfragen für DVS-unterstützende Prozessoren sind in einer Veröffentlichung 
von Burd und Brodersen [76] beschrieben. Die Intel SpeedStep®-Technologie 
hat im Jahr 2004 sechs verschiedene Spannungs-/Frequenzkombinationen bei 
Pentium” M-Prozessoren realisiert [247]. Aktuelle Prozessoren erhalten umfang- 
reichere Mechanismen zur Beeinflussung der Leistungsaufnahme. 


Codegrößen-Effizienz 


Für eingebettete System ist die Minimierung der Codegröße sehr wichtig, da diese 
nur selten über mechanische oder Festkörper-Laufwerke verfügen und die verfügba- 
re Speicherkapazität meist auch sehr beschränkt ist?. Dies wird bei Systems-on-a- 
Chip (SoCs) um so deutlicher. SoCs implementieren Speicher und Prozessoren auf 
demselben Chip. In diesem besonderen Fall wird der Speicher auch eingebetteter 
Speicher genannt. Eingebetteter Speicher kann in der Herstellung teurer als sepa- 
rate Speicherchips sein, da die Herstellungsprozesse für Speicher und Prozessoren 
kompatibel sein müssen. Dennoch kann ein großer Anteil der gesamten Chipfläche 


° Die Verfügbarkeit großer Flash-Speicher und die 3D-Integration lockern die Speicherplatzbe- 
schränkungen ein wenig. 
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durch Speicher belegt sein. Es gibt verschiedene Techniken, um die Codegröße zu 
reduzieren: 


e CISC-Maschinen: Standard RISC-Prozessoren wurden für maximale Geschwin- 
digkeit und nicht für effiziente Codegrößen entworfen. Dagegen wurden frühere 
Prozessoren mit komplexen Befehlen (engl. Complex Instruction Set Compu- 
ters (CISC)) auf effiziente Codegrößen hin optimiert, da sie nur über langsame 
Speicher verfügen konnten. Caches kamen dabei meist nicht zum Einsatz. Da- 
her werden „altmodische” CISC-Prozessoren gerne in eingebetteten Systemen 
eingesetzt. Ein Beispiel dafür sind die ColdFire-Prozessoren [170], die auf der 
68000er-Familie von CISC-Prozessoren der Firma Motorola basieren. 

e Komprimierungstechniken: Durch das Ablegen von Befehlen in komprimierter 
Form im Hauptspeicher lassen sich die Menge an Silizium, die zum Speichern 
der Befehle notwendig ist, und auch die Energie, die zum Laden dieser Befehle 
benötigt wird, reduzieren. Durch die gesunkene Anforderung an die Bandbreite 
kann das Laden von Befehlen auch schneller erfolgen. Ein (hoffentlich schneller 
und kleiner) Dekodierer wird zwischen den Prozessor und den Befehlsspeicher 
geschaltet, um während des Ladens die ursprünglichen Befehle zu erzeugen (siehe 
Abb. 3.18 (rechts))!°. Anstelle eines großen Speichers voller unkomprimierter 
Befehle speichern wir die Befehle nun in einem komprimierten Format. 


uP uP 
Mm 
Befehl r T 
8 Dekoder 
5 
< 


M 

ROM = Befehl 3 
ROM uf 

< 


Abb. 3.18 Holen von Befehlen: links: unkomprimiert; rechts: komprimiert 


Die durch Komprimierung zu erreichenden Ziele umfassen also: 


e Wir möchten ROM- und RAM-Bereiche einsparen, da diese teurer als der eigent- 
liche Prozessor sein können. 

e Wir möchten eine Kodierungstechnik für Befehle und möglicherweise auch für 
Daten mit folgenden Eigenschaften verwenden: 


— Der Aufwand zur Laufzeit soll gering sein. 

— Die Dekodierung sollte mit einem begrenzten Kontext möglich sein (es ist 
beispielsweise nicht möglich, das gesamte Programm einzulesen, um das Ziel 
eines Sprungbefehls zu finden). 


10 Wir stellen die Funktion von Multiplexern, arithmetische Einheiten und Speichern weiterhin 
anhand ihrer Form (und nicht durch Beschriftung) dar, da diese Darstellung in technischer Doku- 
mentation weit verbreitet ist. Für Speicher führen wir Symbole ein, die einen expliziten Adress- 
Dekodierer enthalten (in den Symbolen für ROMs auf der rechten Seite zu sehen). Diese Dekodierer 
kennzeichnen den Adresseingang. 
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— Wortgrößen von Speichern, Befehlen und Adressen sind zu berücksichtigen. 

— Sprungbefehle zu beliebigen Zieladressen müssen unterstützt werden. 

— Eine schnelle Kodierung ist nur erforderlich, wenn veränderliche Informatio- 
nen kodiert werden. Ansonsten reicht eine schnelle Dekodierung aus. 


Es gibt dabei verschiedene Variationen dieses Schemas: 


— Einige Prozessoren verfügen über einen zweiten Befehlssatz mit einem 
„schmaleren” Befehlsformat. Beispielsweise verwendet der normale ARM- 
Befehlssatz 32 Bit breite Befehle. Die meisten ARM-Prozessoren verfügen 
daneben noch über einen zweiten Befehlssatz, die sogenannten THUMB- 
Befehle. THUMB-Befehle sind kürzer, da sie bedingte Ausführung'! nicht 
unterstützen, weniger und kürzere Registerfelder besitzen und auch nur kürze- 
re Direktoperanden (engl. immediate values) aufnehmen können (siehe Abb. 
3.19). 


"981" "10" Rd constant 16-bit Thumb-Befehl 


ADD Rd, #constant 


immer 
y oN ARM-Befehl 


"1110" "001" "01001" 'O'&Rd '@'&Rd "0000"&constant 


Abb. 3.19 Umkodierung von THUMB- in ARM-Befehle 


apoodo sofew 
apoodo Joulw 


THUMB-Befehle werden dynamisch in ARM-Befehle umgewandelt, wahrend 
ein Programm dekodiert wird. Dabei können sie nur die Hälfte der verfügbaren 
Register nutzen. Den Registerfeldern von THUMB-Befehlen wird bei der 
Dekodierung ein 'Q'-Bit vorangestellt!?. Im THUMB-Befehlssatz sind Quell- 
und Zielregister identisch und die Länge von Konstanten, die direkt im Befehl 
kodiert werden können, ist um 4 Bit reduziert. Während der Dekodierung wird 
Fließbandverarbeitung (engl. Pipelining) verwendet, um den Mehraufwand 
zur Laufzeit gering zu halten. 


!! Bei der bedingten Ausführung (engl. predicated execution) haben Befehle nur dann eine Wir- 
kung, wenn eine im Befehl kodierte Bedingung bezüglich der Inhalte der Condition-Code-Register 
erfüllt ist. Beim ARM-Befehlssatz wird dabei die Bedingung in den höchstwertigen vier Bits des 
Befehlsformats gespeichert und so wird beispielsweise ein Befehl nur wirksam, wenn eine vorher 
geprüfte <=-Bedingung erfüllt war. Mit bedingter Ausführung können if-Anweisungen ohne be- 
dingte Sprünge realisiert werden. Die bedingte Ausführung besitzt im neueren 64-Bit-Befehlssatz 
eine geringere Bedeutung. 

12 Unter Verwendung der VHDL-Syntax (siehe Seite 109) wird die Konkatenation durch ein &- 
Zeichen gekennzeichnet und Konstanten werden in Hochkommata eingeschlossen. 
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Ähnliche Techniken existieren auch für andere Prozessoren. Der Nachteil die- 
ses Ansatzes ist es, dass die Entwicklungswerkzeuge (Übersetzer, Assembler, 
Debugger usw.) erweitert werden müssen, um einen zweiten Befehlssatz zu 
unterstützen. Daher kann dieser Ansatz zu hohen Kosten für Entwicklungs- 
werkzeuge führen. 

— Man kann in Wörterbüchern (engl. dictionaries) jedes Befehlsmuster nur 
ein einziges Mal speichern. Für jeden Wert des Programmzählers stellt dann 
eine Index-Tabelle (engl. look-up-table) einen Zeiger auf den entsprechenden 
Befehl in der Befehlstabelle, dem Wörterbuch, bereit (siehe Abb. 3.20). 


Befehisadiesse \<---- Zeiger auf Befehle 


<< 32 Bits 


Tabelle benutzter Befehle |<--- wenige Einträge 


3" 32 Bits 
HP 


Abb. 3.20 Wörterbuch-Ansatz zur Befehlskomprimierung 


Wenn nur sehr wenige unterschiedliche Befehlsmuster verwendet werden, be- 
nötigt die Befehlstabelle nur sehr wenige Einträge. Entsprechend kann die 
Bitbreite der Zeiger sehr schmal ausfallen. Abwandlungen dieses Schemas 
sind u.a. als Steuerspeicher mit zwei Ebenen (engl. two-level control store) 
[119], Nanoprogrammierung [514] oder Procedure-Exlining [551] bekannt. 


Beszedes [52] und Latendresse [325] geben einen Überblick über bekannte Kom- 
primierungstechniken. Außerdem publizierten Bonny et al. [58] eine Technik auf 
der Basis von Huffman-Kodierungen. 


Laufzeiteffizienz am Beispiel Digitale Signalverarbeitung (DSP) 


Um Zeitbedingungen einhalten zu können, ohne hohe Taktfrequenzen zu verwen- 
den, können Architekturen für bestimmte Anwendungsbereiche, wie beispielsweise 
die digitale Signalverarbeitung (engl. Digital Signal Processing (DSP)), angepasst 
werden. Eine sehr häufige Operation der digitalen Signalverarbeitung ist das digitale 
Filtern. Wir erweitern nun das Verarbeitungsfließband aus Abb. 3.8 auf Seite 149 
um einen solchen Filter, wie in Abb. 3.21 gezeigt. 

Die Gleichung (3.21) beschreibt einen digitalen Filter, der aus einem Eingangssi- 
gnal w(t) das Ausgangssignal x(t) erzeugt. Beide Signale sind über den (normaler- 
weise unbegrenzten) Zeitbereich {t,} der Abtastwerte definiert. Wir schreiben kurz 
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I Anti- | =] Sample- |= | ap- | 2 |Verar | = 
aliasing & hold Konv. beitung 
Abb. 3.21 Namenskonvention für Signale 
x, anstelle von x(ts) und WwWs-n+k+1 anstelle von w(ts-n+k+1)!°: 
n-1 
Xs = È | Ws-nikt1 * Gk (3.21) 
k=0 


Ein bestimmtes Ausgabeelement x, entsteht aus dem gewichteten Mittelwert der 
letzten n Signalelemente von w und kann iterativ berechnet werden, wobei in jeder 
Iteration ein Produkt addiert wird. Prozessoren fiir DSP sind so ausgelegt, dass jede 
Iteration als ein einziger Befehl dargestellt werden kann. 


Beispiel 3.5: Dies ist möglich mit den DSP-Prozessoren der Familie ADSP 2100, 
deren interne Architektur in Abb. 3.22 gezeigt ist. 


Adress- 
register Ga (a 
Ka, 
M@-M7, 
L@-L7 


Address 
generation 
unit (AGU) 


Se Se 


Abb. 3.22 Interne Architektur der Prozessorfamilie ADSP 2100 (vereinfacht) 


Die Architektur verfiigt tiber zwei Speicher DM und PM. Eine Adresserzeugungs- 
Einheit (engl. Address Generating Unit (AGU)) kann Zeiger für den Zugriff auf 


13 In unserer Notation ist ag das Gewicht des ältesten Wertes. Definiert man ag als Gewicht des 
jüngsten Wertes von w, so nimmt der erste Term die gebräuchlichere Form w,_; an. Unsere 
Notation dient der Vorbereitung des nachfolgenden Programmcodes. 
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diese Speicher in Indexregistern 10-17 bereitstellen. Es gibt separate Einheiten für 
Additionen und Multiplikationen mit eigenen Parameterregistern AX0, AY®, AF, MXQ, 
MYO und MF. Der Multiplizierer ist mit einem zweiten Addierer verbunden, um die 
Folge von Multiplikationen und Additionen (sog. MAC-Operationen) schnell be- 
rechnen zu können. Dieser Prozessor führt eine Iteration in einem Zyklus aus. Dafür 
wird für die Arrays w und a Speicherplatz in den beiden Speichern reserviert. 

Zeiger auf die Arrayelemente werden in Indexregistern gehalten, auf die in der 
AGU bei jeder Iteration der Inhalt eines der Modify-Register MQ-M7 addiert wird. 
Dies wird meist als Nebeneffekt der Zugriffe auf die Arrays kodiert. — Teilsummen 
werden in MR gespeichert. 

Würden wir jeweils das nächste eintreffende Folgenelement in einem freien Spei- 
cherelement ablegen, so würde der Speicherbedarf im Laufe der Zeit wachsen, und 
zwar unbegrenzt. Die Größe des Arrays w kann aber beschränkt werden, da wir nur 
Zugriff auf die n aktuellsten Werte benötigen. Die Wiederverwendung von Speicher 
ist durch Verwendung eines Ringpuffers und den Einsatz von Modulo-Adressierung 
realisierbar. Zu diesem Zweck werden die in Abb. 3.22 zu sehenden Längenregister 
LQ-L7 benutzt. Wenn in einem geeigneten Register der Grad n des Filters abgelegt 
wird, erfolgt die Adressierung des Speichers modulo n. 

Die erwähnten Register haben offenbar verschiedene Aufgaben, sie sind hetero- 
gen. Heterogene Registersätze sind für DSP-Prozessoren charakteristisch. 

Um Zyklen für das Testen auf das Schleifenende einzusparen, stellen DSP- 
Prozessoren häufig zero-overhead loop instructions bereit. Diese erlauben es, einen 
einzelnen Befehl oder eine kleine Zahl von Befehlen mehrmals zu wiederholen. 

Damit kommen wir zur Vorstellung der Realisierung des Filters aus Gleichung 
(3.21) mit Prozessoren der ADSP 2100-Familie (adaptiert aus [14]): 


/x äußere Schleife über Abtastzeitpunkte ts */ { 


L@ =n; L4 =n; /* Ringpufferlange x/ 

Mil Sas MS = 13 /* Inkrement für Indexregister */ 

Ið = Adresse ältester Wert in w; I4 = Beginn der Filtertabelle a; 

MX® = DMLI®]; MYO = PM[I4]; /* Lade ältestes w[] & ao */ 

MR = ð; IQ = IQ + M1; I4 = IA + M5; /* Ringpuffer-gewahre Addition */ 

for (k=0; k<(n-1); k++) { /* n-1 Iterationen */ 
MR = MR + MX@ * MYO; MX = DM[IQ]; MYO = PM[I4]; /* MAC Operation */ 
IO = 10 + M1; I4 = I4 + M5; /* Ringpuffer-gewahre Addition */ 

} 

MR = MR + MX® * MYO; x[s] = MR; /* MAC für jüngstes Elem. */ 


Die äußere Schleife entspricht den fortschreitenden Abtastzeitpunkten. Zu Beginn 
jeder Filterberechnung erfolgt die Initialisierung der Register. Ein einzelner Befehl 
realisiert den inneren Schleifenkörper, bestehend aus vier Operationen: 


e Lesen von zwei Argumenten aus den Registern MX@ bzw. MY®, Multiplizieren der 
Argumente und Addieren des Ergebnisses zur Teilsumme in Register MR, 

e Laden der nächsten Elemente der Arrays a und w aus den Speichern PM und DM 
und Speichern der Werte in den Argumentregistern MX® und MY®, 
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e Addition von Indexregister Id bzw. 14 und Modify-Register M1 bzw. M5 bei 
Berücksichtigung der Längenregister LO und L4, 
e Testen auf das Schleifenende. 


Für bestimmte Berechnungen kann diese (begrenzte) Form der Parallelität in ver- 
gleichsweise niedrigen Taktfrequenzen resultieren. Prozessoren, die nicht für DSP 
optimiert sind, würden vielleicht mehrere Befehle pro Iteration benötigen und damit 
ggf. eine höhere Taktfrequenz erfordern. V 


Zusätzlich zur Realisierung von Filtern mit Hilfe eines einzigen Befehls im Schlei- 
fenkörper bieten DSP-Prozessoren noch weitere Merkmale, die spezifisch für den 
DSP-Anwendungsbereich sind: 


+ Sättigungsarithmetik: Sättigungsarithmetik verändert die Behandlung von Über- 
und Unterläufen. Die Standard-Binärarithmetik verwendet ein sogenanntes wrap- 
around bei Über- oder Unterläufen. Dabei werden die einzelnen Bits innerhalb der 
darstellbaren Stellen des Ergebnisses so berechnet, als gäbe es keinen Über- bzw. 
Unterlauf. Auftretende Überträge werden einfach ignoriert. Abbildung 3.1 zeigt 
ein Beispiel, bei dem zwei vorzeichenlose Vier-Bit-Zahlen addiert werden. Dabei 
wird ein Übertrag erzeugt, der nicht in einem der Standardregister zurückgegeben 
werden kann. Das Ergebnisregister enthält bei Verwendung von wrap-around ein 
Muster, das nur aus Nullen besteht. Kein Ergebnis könnte weiter vom erwarteten 
Ergebnis entfernt sein als dieses. 


Tabelle 3.1 Vergleich von Wrap- 0111 
around und Sättigungsarithmetik für + 1001 
vorzeichenlose Zahlen Standard wrap-around Arithmetik | 1 0 @ @ @ 

Sättigungsarithmetik 1111 


Bei der Sättigungsarithmetik wird ein Ergebnis erzeugt, das so nahe wie möglich 
am wahren Ergebnis liegt. Die Sättigungsarithmetik gibt den größten möglichen 
Wert zurück, wenn ein Überlauf stattgefunden hat, und den kleinsten möglichen 
Wert im Falle eines Unterlaufs. Dieser Ansatz ist insbesondere für Video- und Au- 
dioanwendungen sinnvoll. Der Benutzer wird im obigen Beispiel wohl kaum den 
Unterschied zwischen dem wahren Ergebniswert und dem größten darstellbaren 
Wert erkennen können. Es wäre auch sinnlos, bei einem Überlauf eine Ausnah- 
me zu signalisieren, da es schwierig wäre, eine solche Ausnahme in Echtzeit zu 
behandeln. Man muss allerdings wissen, ob vorzeichenlose oder vorzeichenbe- 
haftete Zahlen verwendet werden, um den richtigen Ergebniswert zu bestimmen. 
e Festkommaarithmetik: Gleitkommarechnungen besitzen Eigenheiten (siehe 
[186]), die teilweise nicht erwünscht sind. Außerdem erhöht Gleitkommahard- 
ware die Kosten und die Leistungsaufnahme von Prozessoren. Geschätzte 80% 
der DSP-Prozessoren haben daher keine Gleitkommahardware [1]. Zusätzlich 
zur Ganzzahlverarbeitung bieten viele solcher Prozessoren aber die Verarbei- 
tung von Festkommazahlen an. Festkommadatentypen können mit Hilfe eines 
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3-Tupels (wl, iwl, sign) spezifiziert werden, wobei wl die Gesamtwortlänge ist, 
iwl die Ganzzahlwortlänge (also die Anzahl der Stellen links des Binärpunkts) 
und sign € {s,u} zwischen vorzeichenbehafteten und vorzeichenlosen Zahlen un- 
terscheidet (siehe Abb. 3.23). Auch gibt es verschiedene Rundungsmodi (z.B. Ab- 
schneiden) und Überlaufmodi (z.B. Sättigungs- und Wrap-around-Arithmetik). 


Abb. 3.23 Parameter eines Festkommazahlensystems Vorzeichen Binärpunkt 


| 
TTT IT, 


Bei Festkommazahlen bleibt die Position des Binärpunkts nach der Multiplikation 
erhalten (einige der niederwertigen Bits werden abgeschnitten oder gerundet). Bei 
Festkommaprozessoren wird diese Operation direkt von der Hardware unterstiitzt. 

« Echtzeitfahigkeit: Einige der Eigenschaften moderner Prozessoren dienen dazu, 
die durchschnittliche Ausführungszeit von Programmen zu verbessern. In vielen 
Fällen ist es schwierig bis unmöglich, formal nachzuweisen, dass diese Vorkeh- 
rungen auch die längste mögliche Ausführungszeit (engl. Worst Case Execution 
Time (WCET)) verbessern. In solchen Fällen kann es besser sein, auf den Einsatz 
dieser Techniken zu verzichten. Beispielsweise ist es schwierig (aber nicht un- 
möglich, siehe [4]), eine bestimmte Leistungssteigerung durch den Einsatz eines 
Caches zu garantieren. Aus diesem Grunde verzichten viele eingebettete Prozes- 
soren auf den Einsatz von Caches. Ebenso wird man virtuelle Adressierung und 
demand paging [213] (siehe auch Anhang C) üblicherweise nicht in eingebetteten 
Systemen finden. Techniken zur Vorhersage von worst case-Ausführungszeiten 
werden in Unterabschnitt 5.2.2 vorgestellt. 


DSP-Befehle wurden aufgrund der Bedeutung der Signalverarbeitung vielen existie- 
renden Befehlssätzen hinzugefügt. 


Multimedia- und short vector-Befehlssätze 


Die Register und Rechenwerke moderner Prozessorarchitekturen haben häufig ei- 
ne Breite von mindestens 64 Bit. Man kann zwei 32-Bit-Datentypen, vier 16-Bit- 
Datentypen oder acht-8 Bit-Datentypen (Bytes) in ein einziges 64-Bit-Register laden 
(siehe Abb. 3.24). 

Arithmetische Einheiten können so entworfen werden, dass die Überlaufbits an 
den 32-Bit-, 16-Bit- oder 8-Bit-Grenzen unterdrückt, also nicht weitergeleitet, wer- 
den. Multimediabefehlssätze nutzen diese Eigenschaft aus, um Operationen auf so- 
genannten gepackten Datentypen durchzuführen. Solche Befehle werden manchmal 
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OO 64 Bit > 


16-Bit-Wert 3 | 16-Bit-Wert 2 | 16-Bit-Wert1 | 16-Bit-Wert O 


Abb. 3.24 Verwenden eines 64-Bit-Registers für gepackte Datentypen 


Single Instruction, Multiple Data- (SIMD-) Befehle genannt, da ein einziger Befehl 
die auszuführende Operation auf mehreren Datenelementen vorgibt [212]. Bei der 
Verwendung von 8 Bit langen Datentypen in einem 64-Bit-Register sind Geschwin- 
digkeitssteigerungen von etwa einem Faktor von acht gegenüber nicht-gepackten 
Datentypen möglich. Die Daten werden meist im Speicher gepackt abgelegt. So 
kann man das Entpacken und Packen vermeiden, indem man arithmetische Opera- 
tionen direkt auf den gepackten Daten durchführt. Multimediabefehle können i.d.R. 
Sättigungsarithmetik verwenden, um eine effiziente Überlaufbehandlung zu reali- 
sieren. Der Geschwindigkeitsvorteil kann also durchaus größer sein als der Faktor, 
der sich nur aus der Anzahl gleichzeitig bearbeiteter Datenelemente in gepackten 
Datentypen ergibt. Die Vorteile, auf gepackten Daten arbeiten zu können, führten 
dazu, dass bei einer Reihe von Prozessoren entsprechende Befehle ergänzt wurden. 
So wurden z.B. für Intels Pentium®-kompatible Prozessoren [248] Streaming SIMD 
Extensions (SSE) als Befehlssatzerweiterung eingeführt. Solche neuen Befehle wer- 
den auch short vector instructions genannt. Sie wurden von Intel®als die sogenannten 
Advanced Vector Extensions (AVX) [249] realisiert. 


Very Long Instruction Word-Prozessoren 


Die Anforderungen an die Rechenleistung eingebetteter Systeme steigen, insbeson- 
dere im Multimediabereich, in dem moderne Kodierungstechniken und Kryptogra- 
phie eingesetzt werden, stark an. Die in üblichen Hochleistungsrechnern verwen- 
deten leistungssteigernden Techniken sind für eingebettete Systeme ungeeignet: da 
beispielsweise bei PCs die Befehlssatzkompatibilität ein wichtiger Faktor ist, ver- 
wenden die in diesen Systemen eingebauten Prozessoren viele ihrer Ressourcen und 
einen großen Teil der Energie dazu, parallel ausführbare Befehle in einer Anwendung 
zu finden. Trotzdem ist ihre Leistungsfähigkeit oft nicht ausreichend. In eingebet- 
teten Systemen kann man ausnutzen, dass eine Befehlssatzkompatibilität mit PCs 
nicht erforderlich ist. Daher können Befehle verwendet werden, welche die parallel 
ausführbaren Operationen explizit angeben. Diese Prozessoren heißen Explicit Par- 
allelism Instruction Set Computers (EPICs). Bei EPICs wird die Identifizierung von 
parallel ausführbaren Befehle von der Hardware zum Compiler verschoben. 

Man kann sowohl Silizium als auch Energie einsparen, wenn mögliche Parallelität 
nicht mehr zur Laufzeit analysiert werden muss. Als Möglichkeit dazu betrachten 
wir sehr lange Befehlsworte (engl. Very Long Instruction Words (VLIW)). Bei 
VLIW-Prozessoren werden mehrere Operationen oder Befehle in einem sehr langen 
Befehlswort (das manchmal Befehlspaket genannt wird) kodiert und dann parallel 
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ausgeführt. Jede Operation wird in ein bestimmtes Feld des Befehlspakets geschrie- 
ben. Jedes dieser Felder steuert eine bestimmte Hardwareeinheit an. In Abb. 3.25 
werden vier Felder verwendet, von denen jedes eine Hardwareeinheit steuert. 


oo Befehlspaket ————————___> 
Befehl 1 Befehl 2 Befehl 4 


Gleitkomma- | Integer- 
Einheit Einheit 


— 


Abb. 3.25 VLIW-Architektur (Beispiel) 


Speicher- 
Einheit 


Der Compiler muss für VLIW-Architekturen Befehlspakete erzeugen. Dazu muss 
er Informationen über verfügbare Hardwareeinheiten haben, um diese auszulasten. 

Die Felder in den Befehlen sind fest vorgegeben und müssen vorhanden sein, 
unabhängig davon, ob in einem bestimmten Zyklus ein Befehl auf der entsprechenden 
Einheit ausgeführt werden soll. Wenn nicht genügend Parallelität vorhanden ist, 
um alle Einheiten auszulasten, kann die Codedichte von VLIW-Prozessoren daher 
relativ niedrig sein. Dieses Problem kann durch mehr Flexibilität vermieden werden. 
Beispielsweise verwendet die Familie der Texas Instruments TMS 320C6xx-Prozes- 
soren eine variable Befehlspaketgröße von bis zu 256 Bit. In jedem Befehlsfeld 
ist ein Bit reserviert, das angibt, ob die im nächsten Feld angegebene Operation 
parallel ausgeführt werden soll. Wegen der variablen Länge ihrer Befehlspakete sind 
die TMS 320C6xx-Prozessoren keine klassischen VLIW-Prozessoren. Aufgrund der 
explizit beschriebenen Parallelität sind sie aber auf jeden Fall EPICs. 

Die Implementierung der Registersätze für VLIW- und EPIC-Prozessoren ist nicht 
einfach. Wegen der großen Anzahl parallel auszuführender Operationen wird eine 
große Anzahl paralleler Registerzugriffe benötigt. Man benötigt also viele Schreib- 
und Leseports für die Register. Allerdings werden Registersätze mit vielen Ports 
zunehmend langsamer, größer und verbrauchen mehr Energie, sind also ineffizi- 
ent. Daher verwenden viele VLIW/EPIC-Architekturen partitionierte Registersätze. 
Funktionseinheiten werden dann nur an eine Teilmenge der Register angeschlossen. 


VLIW-Fließbänder 


Ein potentielles Problem von VLIW- und EPIC-Architekturen ist ihre möglicher- 
weise große delay penalty. Darunter versteht man Prozessorzyklen, die nicht für 
nützliche Operationen genutzt werden können, weil benötigte Speicherworte nicht 
schnell genug bereitgestellt werden können (z.B. bei Sprungbefehlen). Üblicherwei- 
se werden alle Befehlspakete in einem Fließband (engl. Pipeline) [212] verarbeitet. 
Jede der Fließbandstufen führt nur einen bestimmten Teil der Operationen des je- 
weiligen Befehls aus. Die Tatsache, dass ein Sprungbefehl in einem Befehlspaket 
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enthalten ist, kann nicht direkt in der ersten Fließbandstufe entdeckt werden. Wenn 
die Ausführung des Sprungbefehl endgültig abgeschlossen ist, wurden bereits wei- 
tere Befehle im Fließband bearbeitet (siehe Abb. 3.26). 


elay slots Stufen 


Fließband-_> Befehle holen 
Stufen x F V N X_] Befehle dekodieren 


Sprung) Befehle ausführen 


Ergebnis abspeichern t 


Abb. 3.26 Sprungbefehl und delay slots 


Es gibt im Wesentlichen zwei Methoden, mit diesem potentiellen Leistungsverlust 
umzugehen: 


1. Die Befehle werden so ausgeführt, als wären gar keine Sprungbefehle vorhanden. 
Dieser Fall heißt verzögerter Sprung (engl. delayed branch). Die Befehle des 
Befehlspaketes, die nach dem Sprung noch ausgeführt werden, heißen Befehle in 
branch delay slots. Delay slots können mit Befehlen gefüllt werden, die ohne delay 
slots vor dem Sprung ausgeführt werden würden. Im Allgemeinen schwierig, 
alle delay slots mit sinnvollen Befehlen zu füllen, und so müssen einige mit 
no-operation (NOP)-Befehlen aufgefüllt werden. Der Ausdruck branch delay 
penalty gibt den Geschwindigkeitsverlust aufgrund dieser NOPs an. 

2. Das Fließband wird angehalten, bis die ersten Befehle vom Sprungziel des Sprun- 
ges geladen worden sind. So gibt es keine branch delay slots und die branch delay 
penalty-Zyklen werden durch das Anhalten des Fließbandes verursacht. 


Die branch delay penalties können sich sehr deutlich auswirken. Man kann die 
bedingte Ausführung (engl. predicated execution, siehe Seite 164) von Befehlen 
ausnutzen, um Sprünge aufgrund von if-Anweisungen zu vermeiden. 

Der Crusoe-Prozessor™ ist ein (kommerziell nicht erfolgreiches) Beispiel eines 
EPIC-Prozessors für PCs [296]. Der IA-64 Befehlssatz [250] und seine Implementie- 
rung in den Itanium®-Prozessoren waren der Versuch von Intel, EPIC-Befehlssätze 
im PC-Markt einzuführen. Durch Probleme mit vorhandener Software hatte sich 
aber der Servermarkt als Haupteinsatzgebiet herausgestellt. Viele MPSoC-Systeme 
(siehe Seite 178) verwenden VLIW- und EPIC-Prozessoren. 


Mehrkern-Prozessoren 


Die bislang beschriebenen Merkmale von Einzel-Prozessoren haben geholfen, hoch 
performante Prozessoren auf ressourcengewahre Weise zu entwerfen. Allerdings hat 
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sich gezeigt, dass man beim Versuch einer weiteren Performanzsteigerung gegen die 
sogenannte power wall läuft: über Jahre wurden Taktfrequenzen zwecks Performanz- 
steigerung erhöht, aber eine weitere Steigerung würde in einer zu hohen Stromauf- 
nahme und in zu heißen Schaltkreisen resultieren. Eine weitere Steigerung der Paral- 
lelität in VLIW-Prozessoren war ebenfalls nicht möglich. Aufgrund der Fortschritte 
in der Halbleiterfertigungstechnik ist es mittlerweile machbar, mehrere Prozesso- 
ren auf demselben Halbleiterchip zu fertigen. Wenn man mehrere Prozessoren auf 
demselben Chip fertigt, so nennt man die Prozessoren Mehrkern-Prozessoren. Von 
diesen unterscheiden muss man Multiprozessor-Systeme, wie sie in Rechenzentren 
seit Jahrzehnten im Einsatz sind. Verglichen mit diesen erlaubt die Integration von 
mehreren Kernen auf demselben Chip eine viel schnellere Kommunikation und eine 
gemeinsame Nutzung von Ressourcen (wie z.B. Caches). 


Beispiel 3.6: Abb. 3.27 zeigt die Architektur des Intel® Core™ Duo [540]. 


Prozessor O Prozessor 1 
Kern O Kern 1 Kern 2 Kern3 
CPU CPU CPU CPU 
L1-Cache L1-Cache L1-Cache L1-Cache 
[ L2 Cache | L2 Cache 


jenes Systembus Systemspeicher 


Abb. 3.27 Intel® Core™ Duo-Prozessor 


In diesem Fall sind die L1-Caches den Prozessoren dediziert zugeordnet, wahrend 
der L2-Cache gemeinsam genutzt wird. Selbstverständlich gibt es neben der hier 
aufgeführten Architektur weitere Mehrkern-Architekturen. V 


Bei Mehrprozessor-Systemen muss die Cache-Kohärenz betrachtet werden. Das 
bedeutet, wir müssen wissen, ob Änderungen an Daten und möglicherweise auch 
an Befehlen im Cache durch einen Prozessor auch von den anderen Prozessoren 
gesehen werden. Protokolle für eine automatische Cache-Kohärenz sind seit vielen 
Jahren ein klassisches Thema in der Rechnerarchitektur [212]. Mit dem Aufkommen 
von Mehrkern-Prozessoren sind sie nunmehr auch ein Thema innerhalb eines Chips. 
Dabei können wir von einer wachsenden Zahl von Kernen ausgehen, sodass die 
Skalierbarkeit eine Rolle spielt: für wie viele Kerne können wir eine ausreichende 
Kommunikationsbandbreite bereitstellen, sodass Caches kohärent bleiben? Auch 
taucht die Frage auf, ob die Bandbreite des Speichersystems ausreichend ist, um eine 
wachsende Anzahl von Kernen zu versorgen. 

Im Beispiel der Abbildung 3.27 sind alle Prozessoren von demselben Typ. Wir 
sprechen in diesem Fall von einer homogenen Mehrkern-Architektur. Homogene 
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Mehrkern-Architekturen haben den Vorteil eines begrenzten Entwurfsaufwandes, 
weil die Prozessoren einfach repliziert werden können. Auch kann die Software 
einfach von einem Prozessor zu einem anderen migrieren. Dies ist sehr hilfreich, 
wenn einer der Prozessoren ausfällt. 

Im Unterschied zu homogenen gibt es auch heterogene Mehrkern-Architekturen 
mit unterschiedlichen Prozessoren. Damit können die für bestimmte Anwendungen 
oder bestimmte Szenarien am besten geeigneten Prozessoren gewählt werden. Meist 
benötigt man heterogene Mehrkern-Prozessoren, um die bestmögliche Energieeffi- 
zienz zu erreichen, da nur so eine Anpassung an Anwendungen möglich ist. 

Als Kompromiss zwischen homogenen und (vollständig) heterogenen Architek- 
turen gibt es Architekturen mit einem einheitlichen Befehlssatz (engl. Instruction 
Set Architecture (ISA)) aber unterschiedlichen internen Architekturen, sogenannte 
single-ISA heterogeneous multi-cores [317]. 


Beispiel 3.7: Die ARM® big.LITTLE-Architektur ist ein prominentes Beispiel dafür. 
Abb. 3.28 zeigt die Fließbandarchitektur des Cortex® A-15 Prozessors [165]. 


D1||D2|| D3 
F1| [F2||F3||F4||F5|/D1|/D2|/D8|| R1 || R2 | p14 || P2 
D1||D2|| D3 
11 ||E1| ———— Single Cluster 0 pipe ———>WB 
11 ||E1| ————— Single Cluster 1 pipe ———>WB 
> 11 \|E1|| E2|\E3—— MAC pipe ———————SWB 
11 |{E1][E2_—— (aoe ea pipet E 10] [we 
11 || E1||E2||E3||E4||E5||E6||E7 ||E8| |E9 | |E10} [WB 


Abb. 3.28 ARM® Cortex® A-15 Fließband 


Es ist ein relativ komplexes Fließband mit mehreren Fließbandstufen für das 
Holen von Befehlen, die Befehlsdekodierung, die Befehlsausgabe, die Befehlsaus- 
führung und das Abspeichern der Ergebnisse. Bei diesem Fließband müssen Befehle 
mindestens 15 Stufen durchlaufen, bevor Ergebnisse abgespeichert werden können. 
Eine dynamische Ablaufplanung erlaubt es, Befehle in einer Reihenfolge auszu- 
führen, die sich von derjenigen unterscheidet, in der sie aus dem Speicher geholt 
werden. Dies nennt man out-of-order execution. Mehrere Befehle können innerhalb 
desselben Taktzyklus an die Ausführungseinheiten ausgegeben werden. Dies nennt 
man multi instruction issue. Insgesamt ist diese Architektur sehr performant, aber 
sie hat eine hohe elektrische Leistungsaufnahme. 

Abb. 3.29 zeigt die Fließbandarchitektur des Cortex® A-7 Prozessors [165]. Das 
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Ex1||Ex2-———__ Integer pipe ———————_ > WB 

Fı—r2—>/F3—pel>liss| M1 ]/M2+— MAC pipe ——— WB 
Floating pipe || 

F1 ra K/—— een | F3 U F4 || F5 


Abb. 3.29 ARM® Cortex® A-7 Fließband 


Fließband ist relativ einfach. Die Befehle durchlaufen nach Flautner acht bis elf 
Stufen [165]. Sie werden immer in der Reihenfolge ausgeführt, in der sie aus dem 
Speicher geholt werden. Dies nennt man in-order execution. Es gibt nur eine be- 
grenzte Anzahl von Situationen, in denen zwei Befehle in demselben Taktzyklus an 
die Ausführungseinheiten herausgegeben werden. Dadurch hat die Architektur eine 
geringe Leistungsaufnahme, aber auch nur eine begrenzte Performanz. 

Abb. 3.30 [165] macht es deutlich, wie man zwischen den Optimierungskriterien 
Leistungsaufnahme und Performanz durch Wahl einer der Architekturen abwägen 
kann. Für jede der Architekturen ist dabei durch die Wahl der Betriebsspannung und 
der Taktfrequenz eine Flexibilität hinsichtlich dieser Kriterien gegeben. 
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Abb. 3.30 Tradeoff zwischen Leistungsaufnahme und Performanz auf einem A7- oder A15-Kern 


Für herausfordernde Anwendungen (wie z.B. die Videoverarbeitung) ist offen- 
sichtlich ist der Cortex® A-15-Kern besser geeignet. Für permanent aktive Anwen- 
dungen mit geringen Performanzanforderungen ist der Cortex® A-7 dagegen besser 
geeignet. Hätte ein Mobiltelefon mit teilweise permanent aktiven Anwendungen nur 
Cortex® A-15-Kerne, so wäre das eine Energieverschwendung. 

Daher sind heutige Mehrkern-Chips typischerweise heterogen in dem Sinne, 
dass sie eine Mischung von hoch performanten und energieeffizienten Prozessoren 
enthalten, wie in Abb. 3.31 gezeigt. V 
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Interrupt-Kontrolle 


Abb. 3.31 ARM® big.LITTLE-Architektur 
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Graphikprozessoren 


Früher benutzten viele Rechensysteme spezielle Graphikprozessoren (engl. Graphics 
Processing Units (GPUs)), um eine ansprechende Ausgabe beispielsweise auf Bild- 
schirmen zu erzeugen. Diese fest verdrahteten Prozessoren konnten nur Standard- 
Graphikalgorithmen ausführen und waren damit zu unflexibel. Daher wurden sie 
durch programmierbare GPUs ersetzt und führten so zu allgemeinen Berechnungen 
auf Graphikeinheiten (engl. General Purpose Computation on Graphics Processing 
Units (GPGPU)). Die benötigte Performanz erzielen aktuelle GPUs durch die Mög- 
lichkeit, sehr viele Berechnungen in Form von feingranularen Fäden (engl. Threads) 
gleichzeitig auszuführen. Ziel ist dabei, möglichst viele der zahlreichen gleichartigen 
Recheneinheiten gut auszulasten. 


Beispiel 3.8: Wir betrachten die Multiplikation von zwei großen Matrizen auf einer 
GPU. Abb. 3.32 [212] zeigt eine Abbildung von Berechnungen auf eine GPU. 
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Abb. 3.32 Partitionierung einer Matrixmultiplikation zur Ausführung auf einer GPU 
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Die Matrix wird aufgeteilt in sogenannte Thread-Blöcke. Jeder Thread-Block 
kann auf einen der Kerne in einer GPU abgebildet werden. Jeder Thread-Block 
enthält eine Anzahl von Threads und jeder Thread enthält eine Anzahl von Befehlen. 
Die Gesamtheit der Berechnungen in Abb. 3.32 bezeichnet man als grid. V 


Jeder Kern wird versuchen, durch die Ausführung von Threads einen Rechenfort- 
schritt zu erzeugen. Wenn einige Threads blockieren, weil sie z.B. auf den Speicher 
warten, wird der Kern einen anderen Thread ausführen. Die Befehle innerhalb ei- 
nes Threads können ebenfalls gleichzeitig ausgeführt werden, indem beispielsweise 
mehrere Fließbänder genutzt werden. Thread-Blöcke können auf aktuellen Prozesso- 
ren gleichzeitig ausgeführt werden. Ein schnelles Umschalten zwischen den Threads 
und die sich dadurch ergebende Möglichkeit, Speicherlatenz zu verstecken, sind ein 
wesentliches Merkmal von GPUs. 


Beispiel 3.9: Abb. 3.33 zeigt die Architektur der ARM® Mali™ T880 GPU [22]. 
Die Architektur ist als geistiges Eigentum (engl. Intellectual Property (IP)) de- 
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Abb. 3.33 ARM® Mali™ T880 GPU 


finiert. Es gibt ein sogenanntes synthetisierbares Modell, aus dem heraus eine 
Realisierung erzeugt werden kann. In diesem Modell ist die Anzahl von SC-Kernen 
konfigurierbar. Jeder Kern enthält mehrere Fließbänder zur Ausführung von arith- 
metischen und anderen Befehlen. In jedem Taktzyklus werden so viele Threads 
wie möglich an die Ausführungseinheiten herausgegeben. Die GPU enthält auch 
weitere Komponenten wie z.B. eine Speicherverwaltungseinheit (siehe Anhang C), 
bis zu zwei Caches und eine AMBA® Bus-Schnittstelle. Die Softwareentwicklung 
wird durch eine Schnittstelle zur OpenGL-Bibliothek [484] und zu OpenCL (siehe 
https://www.khronos.org/opencl/) unterstützt. V 


Im Allgemeinen kann auf GPUs energieeffizient gerechnet werden (siehe Unter- 
abschnitt 3.7.3 auf Seite 211). 
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Multiprozessor-Systeme auf einem Chip 


Man kann noch einen Schritt weitergehen und heterogene Mehrkern-Prozessoren 
zusammen mit GPUs und evtl. weiteren Komponenten auf einem Chip integrieren. 


Beispiel 3.10: Abb. 3.34 zeigt ein heterogenes Mehrkern-System, welches eine Mali 
GPU [21] enthält. 
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Abb. 3.34 ARM® big.LITTLE System on Chip (SoC) 


Abb. 3.34 enthält nicht nur Prozessorkerne, sondern auch zusätzliche Elemen- 
te wie Speicherverwaltungseinheiten (engl. Memory Management Units (MMUs), 
siehe Anhang C) und Schnittstellen für externe Geräte. Cache-Kohärenz wird un- 
terstützt, d.h. angeschlossene Caches werden aufgrund von Schreibvorgängen in 
anderen Teilen des Systems ggf. aktualisiert. 

Damit soll vermieden werden, dass für diese Einheiten zusätzliche Chips benötigt 
werden. Im Endergebnis wird ein vollständiges System auf einem Chip integriert. Wir 
sprechen daher von einem System auf einem Chip (engl. System-on-a-Chip (SoC)) 
oder sogar von einem Mehrprozessor-System auf einem Chip (engl. Multi-Processor 
System on a Chip (MPSoC)). V 


Es ist wichtig, für Anwendungen eine geschickte Zuordnung zu MPSoC- 
Prozessoren vorzunehmen, da gezeigt werden kann, dass so eine Energieeffizienz 
nahe der von ASICs erreicht werden kann. Beispielsweise wurde für IMEC’s ADRES 
Prozessor eine Effizienz von 55 * 10° Operationen pro Watt und damit 50% der Ef- 
fizienz von ASICs vorhergesagt [364, 481]. Allerdings ist der Entwurfsaufwand für 
solche Architekturen hoch. 
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Beispiel 3.11: Es gibt MPSoCs, die eine Kombination von bereits vorgestellten Pro- 
zessoren enthalten: 66AK2x MPSoCs von Texas Instruments enthalten ARM®- und 
C66xxx-Prozessoren [530] (siehe Abb. 3.35). Damit wird die Bedeutung der vorge- 
stellten Prozessoren unterstrichen. 
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Abb. 3.35 MPSoC 66AK von Texas Instruments®mit ARM®- und C6xxx-Prozessoren V 


Anzahl und Diversität der Komponenten kann noch größer sein, wie bei speziali- 
sierten Prozessoren für die mobile Kommunikation oder die Bildverarbeitung. 


Beispiel 3.12: Abb. 3.36 zeigt ein vereinfachtes Layout des SH-MobileG1-Chips 
[206]. Es werden hochspezialisierte Prozessoren benutzt, so z.B. für Bildverarbeitung 
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(rot), für GSM- und 3G Mobil-Kommunikation (grün) usw. Zur Einsparung von 
Energie werden unbenutzte Teile des Chips nicht mit Strom versorgt, wodurch diese 
Bereiche zu dark silicon werden (siehe Seite 15). V 


180 3 Hardware eingebetteter Systeme 


Der Ubergang auf spezialisierte Prozessoren erfolgt aufgrund von nachlassenden 
Fortschritten in der Halbleiterfertigung und beim Entwurf von parallelen Prozesso- 
ren. Deshalb soll die Performanz nunmehr mit Spezialprozessoren erhöht werden. 
Dies wurde mit Spezialprozessoren für das Maschinelle Lernen auch schon erreicht. 

Im Jahr 2013 sagte Google vorher, dass es bald zu teuer werden würde, die 
benötigte Rechenleistung für Mustererkennung (z.B. für Spracherkennung) in den 
Rechenzentren bereitzustellen. Daher wurde die Entwicklung von Prozessoren ge- 
startet, die für die schnelle Klassifikation von Mustern mit tiefen neuralen Netzwer- 
ken (engl. Deep Neural Networks (DNNs)) optimiert sein sollten. Die entsprechend 
entwickelte Tensor Processing Unit (TPU) zeigt die Abbildung 3.37. 
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Abb. 3.37 Tensor Processing Unit (TPU), v1, zur schnellen Klassifikation [278, 448] 


Den Kern der TPU bildet ein Feld von 256 x 256 MAC-Einheiten. Damit können 
64k 8-Bit-MAC-Operationen je Taktzyklus ausgeführt werden. 16-Bit-Operationen 
benötigen zwei bis drei Zyklen. DNNs bestehen aus mehreren Ebenen von Berech- 
nungen, wobei auf jeder Ebene MAC-Operationen mit Gewichtsfaktoren erforderlich 
sind. Diese werden realisiert, indem Eingabedaten oder Daten von Zwischenebenen 
durch die MAC-Matrix hindurch „gepumpt” werden. In jedem Zyklus werden 256 
Ergebniswerte verfügbar. Die Version 1 der TPU ist um Faktoren von 29,2 bzw. 
13,3 schneller als übliche CPUs bzw. GPUs. Der Quotient aus Performanz und Leis- 
tungsaufnahme hat sich dabei um Faktoren von 34 bzw. 16 verbessert. Aufgrund des 
Erfolgs hat Google eine zweite und eine dritte Generation von TPUs angekündigt 
[93]. Diese unterstützen auch das Trainieren von DNNs. 
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3.3.3 Rekonfigurierbare Logik 


Fiir viele Anwendungsfalle ist ein vollstandiger Hardwareentwurf und der Einsatz 
von anwendungsspezifischen integrierten Schaltkreisen (ASICs) zu teuer. Anderer- 
seits sind Lösungen, die auf Software basieren, häufig zu langsam oder verbrauchen 
zu viel Energie. Rekonfigurierbare Logik kann dann eine Lösung darstellen, wenn 
die verwendeten Algorithmen effizient in speziell angepasster Hardware implemen- 
tiert werden können. Diese Lösung kann beinahe so schnell sein wie der Einsatz 
von ASICs. Im Gegensatz zu diesen kann die ausgeführte Funktion allerdings durch 
das Ändern von Konfigurationsdaten verändert werden. Wegen dieser Eigenschaften 
findet die rekonfigurierbare Logik in den folgenden Gebieten Anwendung: 


e Prototypen: Moderne ASICs können sehr komplex sein und der Entwurfspro- 
zess ist langwierig und teuer. Daher möchte man häufig einen Prototypen zur 
Verfügung haben, der für Versuche mit dem System verwendet werden kann und 
der sich „fast“ wie das endgültige System verhält. Der Prototyp darf teurer und 
größer als das endgültige System sein. Auch darf sein Stromverbrauch durchaus 
noch höher sein und Zeitbedingungen können entschärft werden. Es ist auch 
möglich, dass der Prototyp nur die wichtigsten Funktionen implementiert. Solch 
ein Prototyp kann dazu verwendet werden, das grundlegende Verhalten des zu 
entwickelnden Systems zu überprüfen. 

e Kleine Stückzahlen: Wenn das zu erwartende Marktvolumen zu klein ist, um 
die hohen Entwicklungskosten für ASICs zu amortisieren, kann rekonfigurierbare 
Logik der richtige Ansatz für Anwendungen sein, die sich nicht allein in Software 
implementieren lassen. 

e Echtzeitsysteme: Das Zeitverhalten FPGA-basierter Systeme lässt sich meist 
sehr genau bestimmen. Daher können FPGAs verwendet werden, um Systeme 
mit vorhersagbarem Zeitverhalten zu implementieren. 

e Anwendungen mit möglicher stark paralleler Verarbeitung: Beispielsweise 
kann die parallele Suche nach bestimmten Mustern sehr effizient in paralleler 
Hardware realisiert werden. Dementsprechend wird rekonfigurierbare Logik bei 
der Suche nach genetischer Information, bei der Suche nach Mustern der Internet- 
Kommunikation, bei Börsendaten, bei der seismischen Analyse usw. eingesetzt. 


Rekonfigurierbare Hardware enthält typischerweise einen Speicher, um die Kon- 
figurationsinformation während des normalen Betriebs der Hardware abzuspeichern. 
Wir unterscheiden zwischen flüchtigem und persistentem Konfigurationsspeicher 
(engl. volatile and persistent configuration memory). Bei persistentem Speicher 
wird die Information nach einem Ausschalten der Betriebsspannung beibehalten. 
Bei flüchtigem Speicher geht sie dagegen verloren und muss beim Start aus einem 
persistenten Speicher (wie einem Flash-Speicher) geladen werden. 

Field programmable gate arrays (FPGAs) sind die häufigste Form rekonfigurier- 
barer Hardware. Diese Schaltungen können „im Feld” (d.h. nach der Herstellung) mit 
Konfigurationsdaten programmiert werden. Sie bestehen aus einer matrixförmigen 
Anordnung von Verarbeitungselementen. 
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Beispiel 3.13: Abb. 3.38 zeigt die spaltenbasierte Struktur der Xilinx® UltraScale 
Architektur [602]'*. Einige Spalten enthalten Ein/Ausgabe-Schnittstellen (als Trans- 
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ceiver bezeichnet), Taktgeber und/oder Speicherschnittstellen. Andere Spalten ent- 
halten konfigurierbare Logikblöcke (engl. Configurable Logic Blocks (CLBs)), 
spezielle Hardware für die digitale Signalverarbeitung und ebenfalls Speicher. CLBs 
sind die Schlüsselkomponenten. Sie stellen auf konfigurierbare Weise logische Funk- 
tionen bereit. 

Die Architektur der Xilinx® UltraScale CLBs wird in Abb. 3.39 [601] gezeigt. 


Abb. 3.39 Xilinx® UltraScale 
CLB (1/8 gezeigt) 
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In dieser Architektur enthält jeder CLB acht Blöcke. Jeder Block enthält zwei 
Register, Multiplexer, einzelne Logikelemente sowie RAM-Speicher, mit dem Lo- 
gikfunktionen über eine Tabelle (engl. Look-Up Table (LUT), in der Abbildung in rot 
gezeigt) realisiert werden können. Jeder RAM-Speicher hat sechs Adresseingänge 
und zwei Ausgänge. Er kann jede Boolesche Funktion von sechs Variablen oder zwei 
Funktionen von fünf Variablen (wobei beide Funktionen gemeinsame Variablen ha- 
ben müssen) realisieren. Mithin können alle 2% bzw. 23? Booleschen Funktionen 
von 6 bzw. 5 Variablen implementiert werden! Dies ist der Schlüssel für die Konfi- 
gurierbarkeit. Manche RAM-Speicher können als gewöhnliche Speicher verwendet 


14 Eine Drehung dieser Abbildung um 90 Grad würde ihre Lesbarkeit verbessern, aber sie würde 
der offiziellen Bezeichnung des Layout-Stils widersprechen. 
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werden. Zusätzlich können die einzelnen Logikelemente konfiguriert werden. Die 
Ansteuerung der Register kann ebenfalls gewählt werden, sodass diese entweder die 
Werte aus den RAM-Speichern oder direkte Eingaben zwischenspeichern. Die Blö- 
cke in einem CLB können so kombiniert werden, dass sich Addierer, Multiplexer, 
Schieberegister oder größere Speicher ergeben. Die Konfiguration bestimmt wei- 
terhin die Auswahl der Eingänge der Multiplexer, die Taktung von Registern und 
Speichern und die Verbindungen zwischen den CLBs. V 


Gegenwärtig verfügbare FPGAs enthalten eine große Anzahl von spezialisierten 
Blöcken, wie z.B. DSP-Hardware, Speicher, schnelle Ein/Ausgabeschnittstellen für 
verschiedene Standards, die Entschlüsselung von Konfigurationsdaten, Debugging, 
Analog-Digital-Wandler, schnelle Taktgeneratoren usw. 


Beispiel 3.14: Die Virtex® UltraScale™ VU13P Schaltkreise enthalten 1728 k LUTs, 
48 Mbit verteilten RAM-Speicher, 94,5 Mbit „Block RAM”, 360 Mbit „UltraRAM”, 
ungefähr 12k spezialisierte DSP Blöcke, 4 PCIe® Blöcke, Ethernet-Schnittstellen 
und bis zu 832 Ein/Ausgabe-Pins [600]. V 


Die Integration von rekonfigurierbarer Logik mit anderen Prozessoren und Soft- 
ware wird bei FPGAs vereinfacht, wenn Prozessoren verfügbar sind, die direkt auf 
dem FPGA implementiert werden können. Hierbei gibt es sowohl hard cores wie 
auch soft cores. Bei hard cores enthält die Schaltung des FPGA bereits einen Be- 
reich, der einen Prozessorkern mit hoher Packungsdichte beinhaltet. Dieser Bereich 
kann ausschließlich für diesen Prozessor verwendet werden. Soft cores dagegen sind 
als synthetisierbare Modelle verfügbar, die dann auf gewöhnliche CLBs abgebildet 
werden. Damit sind sie flexibler, aber auch weniger effizient als hard cores. 


Beispiel 3.15: Der MicroBlaze-Prozessor [598] ist ein Beispiel eines soft cores. V 


Beispiel 3.16: Hard cores sind auf Zynq UltraScale+ MPSoCs verfügbar. Sie ent- 
halten bis zu vier ARM® Cortex-A53 Kerne, zwei ARM Cortex-R5 Kerne und einen 
Mali-400MP2 GPU-Prozessor [602]. V 


Konfigurationen werden üblicherweise aus einer Beschreibung der Funktionalität 
der Hardware auf hoher Ebene, z.B. in VHDL, erzeugt. FPGA-Hersteller stellen 
dazu Entwicklungsumgebungen bereit. Idealerweise sollte man aus derselben Be- 
schreibung automatisch ASICs erzeugen können. In der Praxis gelingt dies nur auf 
interaktive Weise. Da eine automatische Parallelisierung von Anwendungen beim 
gegenwärtigen Stand der Technik selten mit ausreichender Qualität möglich ist, 
setzt eine Ausnutzung der verfügbaren Hardwareparallelität meist voraus, dass An- 
wendungen manuell parallelisiert werden. Die vorhandene Hardwareparallelität wird 
üblicherweise nicht voll ausgenutzt, wenn Operationen lediglich den Prozessoren zu- 
geordnet werden. FPGAs erlauben es, eine große Vielfalt an Hardwareschaltungen 
zu implementieren, ohne dass man andere Hardware als FPGA-Platinen benötigt. 


Beispiel 3.17: Neben Xilinx®bieten auch weitere Hersteller FPGAs an. Darunter be- 
finden sich derzeit (2020) Altera® (siehe http://www.altera.com, durch Intel® über- 
nommen), Lattice Semiconductor (siehe http://www.latticesemi.com), Quicklogic 
(siehe http://www.quicklogic.com), Microsemi (siehe http://www.microsemi.com, 
früher Actel) sowie chinesische Hersteller. 
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3.4 Speicher 
3.4.1 Zielkonflikte 


Daten, Programme und FPGA-Konfigurationen miissen in Speichern abgespeichert 
werden. Speicher müssen so groß sein, wie die Anwendungen es verlangen, sie 
müssen die benötigte Performanz bieten, hinreichend zuverlässig sein, Zugriffe der 
gewünschten Granularität (Bytes, Worte, Seiten) ermöglichen und ggf. persistent 
speichern. Sie müssen dennoch in Bezug auf die Kosten, physikalische Größe und 
den Energieverbrauch effizient sein. Diese Anforderungen führen zu Zielkonflikten, 
was schon 1946 von Burks, Goldstine und von Neumann bemerkt wurde [78]: 

„Ideally one would desire an indefinitely large memory capacity such that any 
particular ... word ... would be immediately available — i.e. in a time which is ... 
shorter than the operation time of a fast electronic multiplier. ... It does not seem 
possible physically to achieve such a capacity.” 

Zugriffszeiten für aktuelle Speicher können mit CACTI abgeschätzt werden. Diese 
Abschätzungen basieren auf der internen Erzeugung eines Layouts des Speichers 
und der Extraktion der Kapazitäten daraus [589]. 


Beispiel 3.18: Abb. 3.40 zeigt Ergebnisse von CACTI für exponentiell wachsende 
Größen [35]. Die Zugriffszeit wächst mit der Größe der Speicher. Abb. 3.40 enthält 
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auch den jeweiligen Energieverbrauch. Danach sind große Speicher nicht energieef- 
fizient. Die Speichergröße hat auf den Energieverbrauch tatsächlich einen größeren 
Einfluss als auf die Zugriffszeit. V 


Uber viele Jahre hinweg ist der Unterschied zwischen den Prozessor- und den 
Speichergeschwindigkeiten immer größer geworden, bis etwa ab dem Jahr 2003 die 
Taktraten von Prozessoren aufgrund der power wall weitgehend stagnierten (siehe 
Abb. 3.41). 

Während die Geschwindigkeit von Speichern sich um einen Faktor von ca. 1,07 
pro Jahr verbessert hat, wurden Prozessoren mit einem Faktor zwischen 1,5 und 
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Abb. 3.41 Unterschied zwischen 
Prozessor- und Speichergeschwindigkeiten 
(bis 2003) 
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2 pro Jahr schneller [359]. Insgesamt ist die Liicke zwischen der Prozessor- und 
der Speichergeschwindigkeit sehr groß geworden und hat eine weitere Erhöhung 
der Performanz erschwert. Die Begrenzung der Performanz durch Speicher ist unter 
dem Begriff memory wall bekannt. Die weitere Erhöhung der Taktraten ist seit dem 
Jahr 2003 weitgehend zum Erliegen gekommen, aber die im Jahr 2003 vorhandene 
Lücke ist damit natürlich noch nicht geschlossen. Mehrkern-Systeme stellen darüber 
hinaus noch zusätzliche Anforderungen an das Speichersystem. Insgesamt müssen 
wir aufgrund der angesprochenen Zielkonflikte günstige Kompromisse zwischen den 
verschiedenen Anforderungen und Randbedingungen finden. 


3.4.2 Speicherhierarchien 


Wegen der beschriebenen Zielkonflikte schrieben Burks, Goldstine und von Neu- 
mann schon 1946 [78]: „We are therefore forced to recognize the possibility of 
constructing a hierarchy of memories, each of which has greater capacity than the 
preceding but which is less quickly accessible”. Die genaue Struktur der Hierarchie 
hängt von technologischen Parametern und dem Anwendungsbereich ab. Üblicher- 
weise können wir mindestens die folgenden Hierarchiestufen identifizieren: 


e Prozessor-Register können als die schnellste Ebene der Speicherhierarchie be- 
trachtet werden, wobei die Kapazität höchstens einige Hundert Worte beträgt. 

¢ Der Arbeitsspeicher (oder Hauptspeicher) realisiert die Speichermöglichkeiten, 
die durch die Adressen üblicher Befehlssätze impliziert werden. Üblicherweise 
hat er eine Kapazität zwischen einigen Megabyte und einigen Gigabyte und er ist 
flüchtig. 

e Typischerweise gibt es eine große Differenz in den Zugriffsgeschwindigkeiten 
zwischen dem Hauptspeicher und den Registern. Aus diesem Grund enthalten 
viele Systeme Pufferspeicher, wie z.B. Caches, Translation Look-aside Buffers 
(TLBs, siehe Anhang C) und/oder Scratchpad Memory (SPM). Im Unterschied zu 
PC-ähnlichen Systemen sollten diese Pufferspeicher möglichst ein vorhersagbares 
Echtzeitverhalten aufweisen. Eine Kombination von kleinen Speichern, die häufig 
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benutzte Informationen enthalten, mit einem großen Speicher für die übrigen 
Informationen ist in der Regel auch energieeffizienter als ein einzelner großer 
Speicher. 

e Die bislang angesprochenen Speicher sind bislang in der Regel flüchtige Speicher. 
Zur dauerhaften Speicherung muss eine andere Technologie benutzt werden. Für 
eingebettete Systeme ist Flash-Speicher häufig die beste Lösung. In anderen Fäl- 
len können Hintergrundspeicher wie Festplatten oder Internet-basierte Lösungen 
(die „Cloud”) eingesetzt werden. 


Speicherhierarchien können genutzt werden, um einen Kompromiss zwischen den 
verschiedenen Entwurfszielen zu erreichen. Hierzu hat A. Macii beispielsweise die 
Speicherpartitionierung genutzt [360]. Neue Speichertechnologien, die teilweise ein 
permanentes Speichern erlauben, haben das Potential, die gegenwärtige Aufteilung 
der Hierarchien zu verändern [389]. 


3.4.3 Registersätze 


Der vorgestellte Einfluss der Speichergröße auf die Zugriffszeiten und die Leistungs- 
aufnahme gilt auch für sehr kleine Speicher wie Registersätze. Abb. 3.42 zeigt die 
Zykluszeit und die elektrische Leistung als Funktion der Größe der Speicher für 
eine Halbleiterfertigungstechnologie mit Strukturbreiten von A = 0,18 um [471]. 
Die elektrische Leistung ist besonders wichtig, weil Registerbänke aufgrund der 
häufigen Zugriffe sehr heiß werden können. 


Zykluszeit [ns] i4 el. Leistung [W] 
1.7 12 
10 

1.5 8 

0,18m 6 0,18um 
1.3 . 

Register- T Register- 
1.1 satz-Größe 2 satz-Größe 


16 32 64 128 16 32 64 128 


Abb. 3.42 Zykluszeit und elektrische Leistung als Funktion der Größe eines Registersatzes 


3.4.4 Caches 


Im Fall von Caches überprüft die Hardware, ob der Cache eine gültige Kopie der In- 
formationen zu einer bestimmten Hauptspeicheradresse enthält. Diese Überprüfung 
beinhaltet einen Vergleich der Tag-Felder, die aus einem Teilbereich der Bits der 
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Hauptspeicheradressen bestehen [212]. Wenn der Cache keine gültige Kopie enthält, 
muss die Information aus dem Hauptspeicher automatisch nachgeladen werden. 
Caches wurden ursprünglich eingeführt, um eine gute Laufzeiteffizienz zu ermög- 
lichen. Der Name ist von dem französischen Wort cacher (verstecken) abgeleitet, 
was darauf deuten soll, dass Programmierer diesen Speicher nicht sehen oder sich 
um ihn kümmern müssen, weil die Aktualisierung des Speichers automatisch durch 
die Hardware erfolgt. Caches sind allerdings nicht mehr so versteckt, wenn große 
Datenmengen adressiert werden. Dies wurde sehr schön von Drepper gezeigt [139]. 
Drepper analysierte die Ausführungszeiten eines Programms, welches eine linea- 
re Liste von Einträgen durchläuft. Jeder Eintrag enthielt NPAD 64-Bit-Worte sowie 
einen 64-Bit-Zeiger auf das Folgeelement. Für einen Pentium P4-Prozessor mit 16 
kB Level-1 Cache und 1 MB Level-2 Cache wurden die Ausführungszeiten bestimmt. 
Dabei wurden für den Level-1 Cache, den Level-2 Cache und den Hauptspeicher Zu- 
griffszeiten von vier, vierzehn und 200 Taktzyklen angenommen. Abb. 3.43 zeigt die 
durchschnittliche Anzahl von Zyklen pro Zugriff auf ein Listenelement als Funktion 
der Gesamtgröße der Liste für den Fall NPAD=0. Für kleine Listengrößen reichen vier 


Zyklen/Zugriff 


TT Tt raw 
gl 6 21 9 922 025 2 28 
Arbeitsmengengröße [Byte] 


Abb. 3.43 Durchschnittliche Anzahl der Zyklen pro Zugriff für NPAD=0 


Zyklen pro Element aus. Dies bedeutet, dass wir fast immer auf den Level-1 Cache 
zugreifen, da dieser für diese Listengröße ausreicht. Für größere Listen benötigen 
wir acht Zugriffe pro Element. In diesem Fall greifen wir fast immer auf den Level-2 
Cache zu. Da der Cache aus Blöcken besteht, die jeweils zwei Listenelemente spei- 
chern können, wird im Mittel nur etwa bei jedem zweiten Listenelement wirklich 
auf den Cache zugegriffen. Für noch größere Listen steigt die Zugriffszeit auf neun 
Zyklen. In diesem Fall ist die Liste größer als der Level-2 Cache, aber das automa- 
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tische Vorabladen von Level-2 Cacheeinträgen versteckt einen Teil der Zugriffszeit 
des Hauptspeichers. 

Abb. 3.44 zeigt die durchschnittliche Anzahl von Zyklen pro Zugriff auf ein Ele- 
ment als eine Funktion der Gesamtgröße der Liste für die Fälle NPAD=0, 7, 15 und 
31. Für NPAD=7, 15 und 31 versagt das Vorabladen aufgrund der größeren Listenele- 
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Abb. 3.44 Durchschnittliche Anzahl der Zyklen pro Zugriff fiir NPAD=0, 7, 15, 31 


mente. Offenbar steigen die Zugriffszeiten dramatisch an und die Cachearchitektur 
hat einen starken Einfluss auf die Ausführungszeit von Anwendungen. Bei größeren 
Caches wird sich lediglich die Größe der Anwendungen verschieben, ab der ein An- 
wachsen der Ausführungszeiten zu beobachten ist. Eine intelligente Ausnutzung der 
Speicherhierarchie kann einen großen Einfluss auf die Ausführungszeiten haben. 

Bislang haben wir uns nur den Einfluss der Caches auf die Zugriffs- bzw. Aus- 
führungszeiten angesehen. Aus dem Kontext der Abb. 3.40 ist aber klar, dass Caches 
auch die Energieeffizienz eines Speichersystems verbessern. 

Es ist schwierig, bereits zur Entwurfszeit vorherzusagen, ob ein Speicherzugriff 
zu einem Treffer im Cache führt oder nicht, was eine präzise Vorhersage des Echt- 
zeitverhaltens erschwert (siehe Seite 269). 


3.4.5 Scratchpad-Speicher 


Als Alternative können kleine Speicher in den Adressbereich des Systems eingeblen- 
det werden (siehe Abb. 3.45). Solche Speicher werden Scratchpad-Speicher (SPM) 
genannt. Auf sie wird zugegriffen, indem eine Adresse aus dem eingeblendeten Be- 
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reich benutzt wird. Im Unterschied zu Caches sind keine Gültigkeitsüberprüfungen 
von Tags zur Laufzeit notwendig. Vielmehr kann man mit einem einfachen Adressde- 
koder überprüfen, ob eine Adresse aus dem eingeblendetem Bereich vorliegt. SPMs 
werden meist zusammen mit den Prozessoren auf demselben Chip integriert. Sie 
sind daher ein Spezialfall von On-Chip-Speichern. Bei n-fach mengenassoziativen 
Caches werden bei Leseoperationen üblicherweise n Einträge parallel gelesen und 
der gesuchte Eintrag anschließend ausgewählt. Dies führt zu einer unnötig hohen 
Energieaufnahme, die für SPMs vermieden wird. Somit sind SPMs in der Regel 
energieeffizienter als Caches. 

Abbildung 3.46 zeigt einen Vergleich zwischen der Energie pro Zugriff auf einen 
SPM und einen Cache. Für einen zweifach mengenassoziativen Cache unterscheiden 


Abb. 3.46 Energie pro Zugriff Energie pro 64-Bit-Zugriff [nJ] 
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sich die Werte in etwa um einen Faktor drei. Die Energiewerte wurden mit Hilfe 
des CACTI-Programms berechnet [589]. Ein detaillierter Vergleich zwischen den 
Zielkriterien für Caches und SPMs wurde von Banakar et al. [35] publiziert. 

Häufig verwendete Variablen und Befehle sollten in den Adressbereich des SPM 
gelegt werden. Speicherzugriffszeiten können auf vorhersehbare Weise gesenkt wer- 
den, wenn Compiler häufig benutzte Variablen oder Befehle einem SPM zuordnen. 
Damit können sich insbesondere bei Echtzeitsystemen Vorteile gegenüber Caches 
ergeben. 


3.5 Kommunikation 


Bevor Informationen in einem eingebetteten System verarbeitet werden können, müs- 
sen sie erst einmal verfügbar sein. Kommunikation ist insbesondere beim Internet 
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der Dinge sehr wichtig. Die Ubertragung der Information kann tiber einen von vielen 
möglichen sogenannten Kanälen erfolgen. Kanäle sind abstrakte Gebilde, die durch 
die Eigenschaften der Kommunikation charakterisiert werden, etwa durch die maxi- 
male Übertragungsgeschwindigkeit oder die Störparameter. Die Wahrscheinlichkeit 
für Fehler bei der Kommunikation wird mit Hilfe von Techniken aus der Kommuni- 
kationstheorie berechnet. Die physikalische Grundlage, auf der die Kommunikation 
erfolgt, wird als Medium bezeichnet. Wichtige Medienklassen sind etwa drahtlo- 
se Medien (Radiowellenübertragung, Infrarot), optische Medien (Lichtwellenleiter) 
oder elektrische Leitungen. 

Bei der Vielzahl von Klassen eingebetteter Systeme gibt es auch viele unterschied- 
liche Anforderungen an die Kommunikation. Im Allgemeinen ist das Verbinden von 
Hardwarekomponenten eingebetteter Systeme alles andere als einfach. Einige häufig 
vorkommende Anforderungen werden im nächsten Unterabschnitt aufgezählt. 


3.5.1 Anforderungen 


Die folgende Liste beschreibt einige Anforderungen, die bei der Kommunikation 
eingehalten werden müssen: 


e Echtzeitverhalten: Diese Anforderung hat weitreichende Auswirkungen auf den 
Entwurf des Kommunikationssystems. Einige kostengünstige Lösungen, wie etwa 
Ethernet, erfüllen diese Anforderung nicht. 

« Effizienz: Die Verbindung zweier Hardwarekomponenten kann recht teuer sein. 
Beispielsweise ist eine direkte Punkt-zu-Punkt-Verbindung in einem großen Ge- 
bäude nahezu unmöglich. Im Automobilbereich hat sich gezeigt, dass separate 
Kabel, welche die Steuereinheiten mit der externen Peripherie verbinden, sehr 
teuer und schwer sind. Einzelne Kabel machen es auch schwierig, neue Kom- 
ponenten anzuschließen. Die Kosten haben auch einen Einfluss auf den Entwurf 
der Stromversorgung externer Geräte. Häufig wird eine zentrale Stromversorgung 
eingesetzt, um Kosten zu sparen. 

e Angemessene Bandbreite und Kommunikationslatenz: Die geforderten Band- 
breiten eingebetteter Systeme unterscheiden sich sehr stark. Die zur Verfügung 
stehende Bandbreite muss den Anforderungen genügen, ohne das System unnötig 
zu verteuern. 

e Unterstützung für ereignisgesteuerte Kommunikation: Systeme, die auf dem 
regelmäßigen Abfragen von Geräten (sogenanntes Polling) basieren, besitzen ein 
sehr gut vorhersagbares Echtzeitverhalten. Die Latenzen können bei dieser Art 
der Kommunikation allerdings zu groß sein. Oft wird eine schnelle, ereignis- 
gesteuerte Kommunikation benötigt. Notfallbedingungen sollten beispielsweise 
sofort weitergeleitet werden und nicht solange unbemerkt bleiben, bis ein zentra- 
les System alle Geräte nach neuen Nachrichten abfragt. 

e Robustheit: Eingebettete Systeme sollen bei extremen Temperaturen oder in der 
Nähe von Quellen elektromagnetischer Strahlung eingesetzt werden. Automo- 
toren können extremen Temperaturen ausgesetzt sein, wie beispielsweise einem 
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Bereich von -20 bis +180°C. Spannungspegel und Taktfrequenzen können von 
solch hohen Temperaturschwankungen beeinflusst werden. Trotzdem muss eine 
verlässliche Kommunikation gewährleistet werden. 

e Sicherheit: Entsprechend der bisher beschriebenen Anforderungen (siehe Sei- 
te 9) ist klar, dass CPS-Systeme betriebssicher und informationssicher sein müs- 
sen. Die Informationssicherheit beinhaltet auch die Vertraulichkeit. Um sicher- 
zustellen, dass private und vertrauliche Informationen geheim bleiben, kann es 
notwendig sein, bei der Kommunikation Verschlüsselungstechniken einzusetzen. 
Die Betriebssicherheit enthält die nachfolgend beschriebenen Aspekte der Feh- 
lertoleranz, Diagnosefähigkeit und Wartbarkeit. 

e Fehlertoleranz: Trotz aller Bemühungen, eine robuste Kommunikation zu errei- 
chen, können Fehler auftreten. Cyber-physikalische Systeme sollten auch nach 
einem solchen Fehler funktionsfähig bleiben. Neustarts, wie sie bei PCs vorkom- 
men, sind inakzeptabel. Wenn eine Kommunikation also fehlgeschlagen ist, sind 
Wiederholungsversuche notwendig. Hier entsteht ein Konflikt mit der ersten An- 
forderung: wenn man mehrere Kommunikationsversuche zulässt, ist es schwierig, 
das Echtzeitverhalten zu garantieren. 

e Diagnosefahigkeit, Wartbarkeit: Cyber-physikalische Systeme müssen in einer 
annehmbar kurzen Zeit repariert werden können. 


Diese Anforderungen an die Kommunikation sind eine direkte Folge der allgemei- 
nen Eigenschaften eingebetteter und cyber-physikalischer Systeme, die in Kapitel 1 
gezeigt wurden. Wegen der Konflikte zwischen einigen der Anforderungen müssen 
in der Praxis Kompromisse eingegangen werden. Beispielsweise kann es unter- 
schiedliche Kommunikationsmodi geben: einen Modus mit hoher Bandbreite, der 
Echtzeitverhalten garantiert, aber keine Fehlertoleranz bietet (diese Übertragungsart 
wäre etwa geeignet für Multimediadaten), und einen fehlertoleranten Modus mit 
geringerer Bandbreite, der z.B. für kurze Nachrichten verwendet wird, die nicht 
verlorengehen dürfen. 


3.5.2 Elektrische Robustheit 


Es gibt einige grundlegende Techniken, um elektrische Robustheit zu erreichen. 
Digitale Kommunikation innerhalb eines Chips findet häufig mit asymmetrischen 
Signalen statt (engl. asymmetric oder single-ended signaling). Dabei werden die 
Signale über eine einzige Leitung geschickt (siehe Abb. 3.47). 

Solche Signale werden durch eine Spannung gegenüber einer einheitlichen Mas- 
se dargestellt, seltener durch unterschiedliche Ströme. Eine einzige Masseleitung ist 
ausreichend für eine größere Anzahl solcher Signale. Asymmetrische Signale sind 
allerdings sehr anfällig für externe Störeinflüsse. Wenn solche Störungen, die z.B. 
durch einen anlaufenden Motor verursacht werden können, die Spannung beein- 
flussen, können Nachrichten verfälscht werden. Es ist auch schwierig, einen genau 
definierten Massepegel zwischen verschiedenen kommunizierenden Einheiten be- 
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Abb. 3.47 Asymmetrische Signale 


reitzustellen, da die Masseleitungen selber auch einen gewissen Widerstand und 
eine Induktivität haben. 


Dies ist bei der symmetrischen oder differentiellen Signalübertragung anders. 


Bei der symmetrischen Übertragung benötigt jedes Signal zwei Leitungen (siehe 
Abb. 3.48). Bei der symmetrischen Signalübertragung werden binäre Werte wie folgt 


symmetrischer 
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Abb. 3.48 Symmetrische Signalübertragung 


kodiert: wenn die Spannung auf der ersten Leitung gegenüber der zweiten positiv 
ist, wird dies als '1' dekodiert, sonst ist der übertragene Wert eine '®'. Die beiden 
Leitungen werden üblicherweise miteinander verdrillt und bilden sogenannte twisted 
pairs. Es gibt lokale Massepegel, aber ein Spannungsunterschied zwischen diesen 
lokalen Massepegeln stört die Kommunikation nicht. Vorteile der symmetrischen 
Signalübertragung sind u.a.: 


Störungen wirken prinzipiell auf beide Leitungen in ähnlicher Weise ein. Beim 
Vergleich werden daher die meisten Störungen entfernt. 

Der Logikwert hängt ausschließlich von der Polarität der Spannung zwischen den 
beiden Leitungen ab. Die Stärke der Spannung kann durch Reflexionen oder den 
Leitungswiderstand verändert werden — dies hat jedoch keinen Einfluss auf den 
übermittelten Wert. 

Signale verursachen keine Ströme auf den Masseleitungen, wodurch die Qualität 
der Masseleitungen weniger kritisch ist. 

Es wird kein gemeinsames Massepotential benötigt. Daher entfällt auch die Not- 
wendigkeit, eine große Anzahl von Kommunikationspartnern mit einem hoch- 
qualitativen gemeinsamen Masseanschluss zu versehen. 

Als Konsequenz der bisher genannten Eigenschaften erreicht die symmetrische 
Signalübertragung i.d.R. eine höhere Übertragungsrate als die asymmetrische 
Übertragung. 
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Allerdings miissen fiir differentielle Signale stets zwei Leitungen fiir jedes Signal zur 
Verfügung stehen. Außerdem benötigt man negative Spannungen, wenn man nicht 
nur jeweils entgegengesetzte Logikpegel der asymmetrischen Signale verwendet. 
Differentielle Signalübertragung wird beispielsweise in Ethernet-basierten Netz- 
werken sowie beim Universal Serial Bus (USB) verwendet. 


3.5.3 Echtzeitgarantien 


Computer verwenden für die interne Kommunikation dezidierte Punkt-zu-Punkt- 
Verbindungen oder gemeinsame Busse. Punkt-zu-Punkt-Verbindungen können ein 
gutes Echtzeitverhalten besitzen, erfordern aber eine große Anzahl an Verbindungen, 
zudem kann es zu Überlastsituationen bei den Empfängern kommen. Verbindungen 
mit gemeinsamen Bussen sind einfacher zu realisieren. Solche Busse verwenden 
meist eine prioritätenbasierte Zuteilung, wenn mehrere gleichzeitige Zugriffe auf 
den Bus vorliegen (siehe z.B. [212]). Das Zeitverhalten prioritätenbasierter Zutei- 
lung ist schlecht vorhersagbar, da Konflikte zur Entwurfszeit nur schwer zu erkennen 
sind. Prioritätsbasierte Schemata können auch zum ‚„Verhungern” führen (Kommu- 
nikation mit niedriger Priorität kann von solcher mit höherer Priorität vollständig 
blockiert werden). Um dieses Problem zu umgehen, kann Time Division Multiple 
Access (TDMA) verwendet werden. Dabei wird die Kommunikationszeit in Rah- 
men (engl. Frames) aufgeteilt. Jeder Rahmen beginnt mit einem Zeitintervall zur 
Synchronisation und evtl. einer Lücke, die es dem Sender erlaubt, sich abzuschalten 
(siehe Abb. 3.49, [303]). 


< Rahmen > 
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sync | lücke sync 
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=—— _ Zeitscheibe -—————>| 


Abb. 3.49 TDMA-basierte Kommunikation 


Nach dieser Lücke folgen eine Anzahl an Zeitscheiben (engl. slices), von de- 
nen jede eine Nachricht enthält. Auch jede Zeitscheibe enthält wieder eine Lücke 
und einen Sicherheitsabstand (engl. guard time), um die Taktratenunterschiede der 
Kommunikationsteilnehmer auszugleichen. Zeitscheiben sind jeweils einem Kom- 
munikationsteilnehmer zugeordnet. Es existieren Abwandlungen dieses Schemas; so 
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ist es z.B. möglich, nicht verwendete Zeitscheiben zu vermeiden oder auch, eine 
Zeitscheibe mehreren Kommunikationsteilnehmern zuzuordnen. TDMA reduziert 
die maximal verfügbare Menge an Daten pro Rahmen und Kommunikationsteil- 
nehmer, garantiert dafür aber eine bestimmte Bandbreite für jeden Teilnehmer. Das 
Verhungern kann dabei vermieden werden. Der AMBA-Bus von ARM®T[20] bein- 
haltet ein Verfahren zur TDMA-basierten Buszuteilung. 

Die meisten Rechnernetzwerke basieren auf den Ethernet-Standards. Für die 
10 MBit/s- und 100 MBit/s-Versionen kann es zwischen den Kommunikationspart- 
nern zu Kollisionen bei der Datenübertragung kommen. Das bedeutet, dass mehrere 
Partner zur gleichen Zeit versuchen, Daten zu übertragen, wodurch sich die Signale 
auf den Leitungen stören. Jedes Mal, wenn das passiert, müssen die Kommunika- 
tionspartner die Kommunikation einstellen, einige Zeit warten und es dann erneut 
versuchen. Die Wartezeit wird zufällig bestimmt, um die Wahrscheinlichkeit für 
einen erneuten Konflikt beim nächsten Versuch zu reduzieren. Diese Methode heißt 
Carrier-Sense Multiple Access/Collision Detect (CSMA/CD). Bei Verwendung von 
CSMA/CD können die Kommunikationszeiten sehr lang werden, da Konflikte sich 
häufig wiederholen können, obwohl dies nicht sehr wahrscheinlich ist. Daher kann 
CSMA/CD nicht eingesetzt werden, wenn Echtzeitbedingungen eingehalten wer- 
den müssen. Das Problem kann mit Hilfe von CSMA/CA (Carrier-Sense Multiple 
Access/Collision Avoidance) vermieden werden. Kollisionen werden bei diesem 
Verfahren komplett vermieden, anstatt sie nur zu entdecken und darauf zu reagieren. 
Bei CSMA/CA gibt es für jeden Kommunikationspartner eine Priorität. Das Über- 
tragungsmedium wird den Partnern während sogenannter Arbitrierungsphasen zu- 
geordnet, darauf folgen dann die eigentlichen Kommunikationsphasen. Während der 
Arbitrierungsphase geben die Partner ihren Kommunikationswunsch auf dem Über- 
tragungsmedium bekannt. Wenn ein anderer Teilnehmer mit einer höheren Priorität 
ebenfalls senden möchte, müssen alle anderen ihren Kommunikationswunsch sofort 
zurückziehen. 

Unter der Annahme, dass es eine obere Schranke für die Zeit zwischen den Arbi- 
trierungsphasen gibt, garantiert CSMA/CA ein vorhersagbares Echtzeitverhalten für 
den Kommunikationspartner mit der höchsten Priorität. Für die anderen Teilnehmer 
kann das Echtzeitverhalten nur dann garantiert werden, wenn die höher priorisierten 
Partner nicht andauernd senden möchten. 

Hochgeschwindigkeitsversionen von Ethernet (> 1 GBit/s) basieren auch auf der 
Vermeidung von Kollisionen. TDMA-Schemata werden auch für drahtlose Kommu- 
nikation verwendet. So setzen Mobilfunk-Standards wie GSM ein TDMA-Verfahren 
zum Zugriff auf das Kommunikationsmedium ein. 


3.5.4 Beispiele 


e Sensor-Aktuator-Busse: Sensor-Aktuator-Busse ermöglichen die Kommunika- 
tion zwischen einfachen Geräten wie etwa Schaltern und Lampen und den da- 
tenverarbeitenden Geräten. Die Anzahl der angesteuerten Geräte kann sehr groß 
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werden, daher miissen die Kosten der Verdrahtung in diesem Fall besonders 
beachtet werden. 

e Feldbusse: Feldbusse sind den Sensor-Aktuator-Bussen ähnlich, sie unterstützen 
jedoch im Allgemeinen höhere Datenraten. Beispiele für Feldbusse sind u.a. 
folgende: 


— Der CAN (Controller Area Network)-Bus: Dieser Bus wurde 1981 von Bosch 
und Intel entwickelt, um Steuereinheiten und Peripherie zu verbinden. Er 
ist insbesondere im Automobilbereich beliebt, da man mit dem CAN-Bus 
eine große Anzahl von Leitungen durch einen einzigen Bus ersetzen kann. 
Wegen der Größe des Automobilmarktes sind CAN-Komponenten verhält- 
nismäßig preiswert und werden daher auch in anderen Bereichen, etwa zur 
Heimautomatisierung und in Fabriksteuerungen eingesetzt. CAN basiert auf 
einer differentiellen Signalübertragung und einer Arbitrierung mittels CS- 
MA/CA. Die Kodierung der Signale erfolgt ähnlich wie bei der seriellen 
RS-232-Übertragung früherer PCs mit Modifikationen für differentielle Si- 
gnalübertragung. Die CSMA/CA-basierte Buszuteilung verhindert nicht das 
Verhungern. Dies ist ein inhärentes Problem des CAN-Busses. Es gibt Erwei- 
terungen. 

— Das Time-Triggered-Protocol (TTP) für fehlertolerante Sicherheitssysteme, 
z.B. Airbags in Autos [305]. 

— FlexRay™ ist ein TDMA-Protokoll, das vom FlexRay-Konsortium (bestehend 
aus BMW, Daimler-Chrysler, General Motors, Ford, Bosch, Motorola und 
Philips Semiconductors) ausgearbeitet wurde und später zum ISO-Standard 
ISO 17458-1:2013 [254] wurde. 

Das FlexRay-Protokoll sieht statische und dynamische Buszuteilungsphasen 
vor. Die statische Phase verwendet ein TDMA-ähnliches Schema. Sie kann 
für echtzeitkritische Kommunikation eingesetzt werden und ist in der Lage, 
Verhungern zu vermeiden. Die dynamische Phase stellt dagegen eine hohe 
Bandbreite für nicht echtzeitkritische Kommunikation zur Verfügung. 

Die levi-Simulation ermöglicht es, das Protokoll zu simulieren [495]. 

— LIN (Local Interconnect Network) ist ein preisgünstiger Kommunikations- 
standard zur Verbindung von Sensoren und Aktuatoren im Automobilbereich 
[347]. 

— MAP ist ein Bus, der fiir Automobilfabriken entworfen wurde. 

— Der European Installation Bus (EIB) wurde fiir die Heimautomatisierung 
entwickelt. 


° Der Inter-Integrated Circuit (C) - Bus ist ein einfacher kostengünstiger Bus, 
der fiir die Kommunikation tiber kurze Distanzen (Meter-Bereich) mit relativ 
niedrigen Datenraten entworfen wurde. Der Bus benötigt nur vier Leitungen: je 
eine für Masse, SCL (Takt), SDA (Daten) und die Betriebsspannung. Daten- und 
Taktleitungen sind Open Collector-Leitungen (siehe Seite 99). Folglich können 
verbundene Geräte diese Leitungen gegen Masse ziehen. Separate Widerstände 
werden benötigt, um diese Leitungen ggf. mit einer schwachen '1' im Sinne 
der CSA-Theorie (siehe Seite 98) zu verbinden. Die Standardgeschwindigkeit ist 
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100 kb/s, aber es existieren auch Versionen mit 10 kb/s und bis zu 3,4 Mb/s. Die 
Spannung auf der Betriebsspannungsleitung kann zwischen den verschiedenen 
Schnittstellen unterschiedlich sein. Es ist lediglich definiert, wie '@' und '1' - 
Pegel relativ zur Betriebsspannung erkannt werden. Der Bus wird von verschie- 
denen Microcontroller-Platinen unterstiitzt. 

e Drahtgebundene Multimediakommunikation: Diese erfordert höhere Daten- 
raten. Beispiel: MOST (Media Oriented Systems Transport) ist ein Kommuni- 
kationsstandard fiir Multimedia- und Infotainmentsysteme im Automobilbereich 
[403]. Standards wie z.B. IEEE 1394 (FireWire) können ebenfalls für diesen 
Zweck verwendet werden. 

« Die Drahtlose Kommunikation wird immer beliebter. 


— Mobile Kommunikation bietet wachsende Datenraten an. Mit HSPA (High 
Speed Packet Access) werden 7 MBit/s erreicht. Long-Term Evolution (LTE) 
bietet etwa 10-fach höhere Datenraten. Für 5G-Netzwerke werden zwischen 
50 MBits/s und mehr als einem Gigabit/s bei geringer Latenz erwartet. 

— Bluetooth ist ein Standard, um Geräte wie Mobiltelefone, Kopfhörer, drahtlose 
Lautsprecher und Audiosysteme in Fahrzeugen miteinander zu verbinden. 

— Wireless Local Area Networks (WLANs): Die drahtlose Ethernet-Version 
wurde von der IEEE als 802.11 standardisiert. Es gibt diverse Erweiterungen. 
Dieser Standard wird in lokalen Netzwerken verwendet. 

— ZigBee (siehe http://www.zigbee.org) ist ein Kommunikationsprotokoll zur 
Erzeugung persönlicher lokaler Netzwerke mit geringer Funkenergie. Es gibt 
Anwendungen beim Internet der Dinge und in der Heimautomatisierung. 

— Digital European Cordless Telecommunications (DECT) ist ein Europäischer 
Standard für Schnurlostelefone. Er wird in der ganzen Welt benutzt, bis auf die 
in Nord-Amerika unterschiedlichen Frequenzen (siehe https://en.wikipedia. 
org/wiki/Digital_Enhanced_Cordless_Telecommunications). 


3.6 Ausgabe - Schnittstelle zwischen Cyber- und physischer Welt 


Zum CyPhy-Interface gehören auch die Ausgabegeräte, wie beispielsweise die 
folgenden: 


e Anzeigen: Die Technologie von Anzeigen (engl. display technology) ist sehr 
wichtig, deshalb gibt es darüber sehr viele Informationen [503]. Große Forschungs- 
und Entwicklungsanstrengungen haben zu neuen Anzeigetechnologien wie etwa 
organischen Anzeigen (engl. organic displays) [345] geführt. Organische An- 
zeigen können mit einer sehr hohen Dichte hergestellt werden. Im Gegensatz 
zu Liquid Crystal Displays (LCDs) benötigen sie keine Hintergrundbeleuchtung 
und polarisierende Filter, da sie selber Licht aussenden können. Deshalb werden 
grundlegende Veränderungen des Anzeigegerätemarktes erwartet. 

° Elektromechanische Geräte: Diese Geräte beeinflussen ihre Umgebung durch 
Motoren und andere elektromechanische Bauteile. 
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Es werden sowohl analoge als auch digitale Ausgabegeräte verwendet. Im Falle 
analoger Ausgabegeräte muss die digitale Information zuerst mittels eines Digital- 
Analog-Wandlers (D/A-Wandlers) in analoge Werte konvertiert werden. Diese Kon- 
verter befinden sich entlang des Pfades von den analogen Eingängen bis hin zu 
ihren Ausgängen. Abb. 3.50 zeigt die Namenskonventionen für die Signale, die wir 
im Folgenden verwenden. Zweck und Funktion dieser Signale werden jeweils im 
Zusammenhang erläutert. 
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Abb. 3.50 Namenskonventionen für Signale zwischen analogen Ein- und Ausgängen 


3.6.1 D/A-Wandler 


D/A-Wandler sind ebenfalls Teil des CyPhy-Interfaces cyber-physikalischer Syste- 
me. Abbildung 3.51 zeigt den Schaltplan eines einfachen D/A-Wandlers. 
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Abb. 3.51 D/A-Wandler 


Die Grundidee hinter diesem Wandler ist, zunächst einen Strom zu erzeugen, der 
proportional zu dem Wert eines digitalen Signals x ist. Solch ein Strom kann aber nur 
schwer von einem nachgeschalteten System direkt verwendet werden. Daher wird 
dieser Strom in eine proportionale Spannung y gewandelt. Diese Wandlung über- 
nimmt ein Operationsverstärker (in Abb. 3.51 als Dreieck dargestellt). Wesentliche 
Eigenschaften von Operationsverstärkern werden in Anhang B erklärt. 

Wie berechnen wir nun die Ausgangsspannung y? Wir betrachten die vier Wi- 
derstände auf der linken Seite der Abb. 3.51. Der Strom durch jeden Widerstand 
ist Null, wenn das entsprechende Element des digitalen Signals x = '@' ist. Wenn 
das Bit den Wert '1' hat, entspricht der Strom durch den Widerstand dem Gewicht 
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dieses Bits, da die Widerstandswerte entsprechend gewählt werden. Wir betrachten 
nun die durch die gestrichelte rote Linie markierte Masche in Abb. 3.51. Wir kön- 
nen die Kirchhoffsche Maschenregel (siehe Anhang B) auf die Masche anwenden, 
die vom niederwertigsten Bit x9 von x gesteuert wird. Wir beginnen den Durchlauf 
durch die Masche beim Widerstand und durchlaufen die Masche anschließend im 
Uhrzeigersinn. Der zweite Term ist die Spannung V_ zwischen den Eingängen des 
Operationsverstärkers. Sie wird positiv gezählt, da wir in Richtung des Pfeils vorge- 
hen. Der dritte Term ist negativ, da wir entgegen der Pfeilrichtung laufen. Damit ist 


Xo * Io * 8 * R + V- — Vef =0 (3.22) 


V_ ist ungefähr 0 (siehe Anhang B). Daraus folgt 


(3.23) 


Entsprechende Gleichungen gelten für die Ströme /ı bis J3 durch die anderen Wi- 
derstände. Wir können jetzt die Kirchhoffsche Knotenregel (siehe Anhang B) auf 
den Knoten anwenden, der alle Widerstände verbindet. An diesem Knoten muss der 
Ausgangsstrom gleich der Summe der Eingangsströme sein. Damit ergibt sich 


I=h+h+l +o (3.24) 
I= x3 * f + ref +x] * ref + x9 ref 
2x R 4x R 8+R 
A 3 
= ra iy nea (3.25) 
i=0 


Jetzt können wir die Maschenregel auf die Masche anwenden, die aus Rı, y und V_ 
besteht. Da V_ ungefähr 0 ist, folgt: 


y+R +! =0. (3.26) 


Wir können die Knotenregel auf den Knoten anwenden, der /, I’ und den inver- 
tierenden Signaleingang des Operationsverstärkers verbindet. Der Strom an diesem 
Eingang ist praktisch gleich Null. Die Ströme / und 7’ sind damit gleich (J = 1’). 


y+Rı*1=0 (3.27) 


Aus den Gleichungen (3.25) und (3.27) folgt: 


3 


R ; R 
Y = -Vref * = * 2, xi x 253 = — ref * 3 T x nat(x) (3.28) 


nat ist die natürliche Zahl, die durch den Bitvektor x dargestellt wird. Offensicht- 
lich ist die Spannung am Ausgang proportional zur durch x dargestellten Zahl. 
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Positive Ausgangsspannungen und Bitvektoren, die Zahlen im Zweierkomplement 
darstellen, erfordern kleine Erweiterungen des D/A-Wandlers. Ähnlich wie bei Ana- 
log/Digitalwandlern ist die erforderliche Genauigkeit der Widerstände ein potenti- 
elles Problem, v.a. bei großen Wortbreiten von x. Als Alternative wird daher die 
Pulsbreitenmodulation verwendet (siehe Unterabschnitt 3.6.3). 

y(t) ist eine Funktion über einem diskreten Zeitbereich: sie stellt eine Folge von 
Spannungspegeln dar. Im Beispiel ist sie nur über ganzzahlige Zeitwerte definiert. 
Dies ist in Anwendungen unpraktisch, da wir meist den Ausgang der Schaltung 
aus Abb. 3.51 kontinuierlich betrachten. Daher werden D/A-Wandler oft durch eine 
zero-order hold-Funktionalität erweitert. Diese bewirkt, dass der Wandler den 
vorherigen Wert beibehält, bis der folgende Wert gewandelt wurde. Der D/A-Wandler 
aus Abb. 3.51 verhält sich in der Tat genau so, wenn wir die Stellung der Schalter 
bis zum nächsten diskreten Zeitpunkt nicht ändern. Damit liegt am Ausgang des 
Wandlers eine Treppenfunktion y’(r) an, die der Folge y(t) entspricht!>. y’(r) ist eine 
Funktion tiber dem kontinuierlichen Zeitbereich. 

Wir betrachten als Beispiel das Ausgangssignal der Wandlung des Signals von 
Gleichung (3.3) mit einer Auflösung 0,125. Für diesen Fall zeigt Abb. 3.52 y’(f). 
y’(t) ist als Treppenfunktion einfacher zu visualisieren als die Funktion y(t), die nur 
für diskrete Zeitpunkte definiert ist. 
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Abb. 3.52 y’(r) (rot) erzeugt aus e3(t) (Gl. (3.3), blau), zu ganzzahligen Zeitpunkten abgetastet 


D/A-Wandler ermöglichen eine Wandlung von zeit- und wertediskreten Signa- 
len in Signale über kontinuierlichen Zeit- und Wertebereichen. Dabei stellen aber 
offensichtlich weder y(t) noch y’(t) die Werte des Eingangssignals zwischen den 
Abtastzeitpunkten dar. 


15 In der Praxis sind die Übergänge von einem Schritt zum nächsten wegen von Null verschie- 
dener Anstiegs- und Fallzeiten des Signals nicht ideal, sondern benötigen eine gewisse Zeit zur 
Stabilisierung. 
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3.6.2 Abtasttheorem 


Nehmen wir an, dass die Prozessoren in der beschriebenen Hardwareschleife einge- 
hende Daten von den A/D-Wandlern unverändert zu den D/A-Wandlern weiterleiten. 
Wir könnten uns auch vorstellen, dass wir die Werte x(t) auf einer CD speichern und 
daraus ein hervorragendes analoges Audiosignal erzeugen wollen. Wäre es möglich, 
die ursprüngliche analoge Spannung e(t) (siehe Abb. 3.8, Abb. 3.21 und Abb. 3.50) 
an den Ausgängen des D/A-Wandlers wieder zu erzeugen? 

Offensichtlich ist diese Rekonstruktion nicht möglich, wenn Aliasing gemäß Abb. 
3.7 auf Seite 148 auftritt!®. Wir nehmen also an, dass die Abtastrate mehr als doppelt 
so groß wie die höchste Frequenz ist, die bei der Aufspaltung des Eingangssignals 
in Sinuswellen auftritt (Abtastkriterium, siehe Gl. (3.8)). Erlaubt uns die Einhaltung 
dieses Kriteriums die Rekonstruktion des ursprünglichen Signals? Schauen wir uns 
das einmal genauer an! 

Wenn man an einen D/A-Wandler eine diskrete Folge digitaler Werte anlegt, so 
wird daraus eine Folge analoger Werte erzeugt. Die Werte des Eingangssignals, die 
zwischen den Abtastzeitpunkten lagen, werden vom D/A-Wandler nicht erzeugt. Die 
beschriebene einfache zero-order-Haltefunktion (wenn vorhanden) würde nur eine 
Treppenfunktion erzeugen. Dies scheint darauf hinzudeuten, dass zur Rekonstruktion 
von e(t) eine unendlich hohe Abtastrate erforderlich ist, damit alle Zwischenwerte 
erzeugt werden können. 

Es könnte aber eine Art geschickter Interpolation geben, die Werte zwischen den 
Abtastzeitpunkten aus den Werten an den Abtastzeitpunkten berechnet. In der Tat 
zeigt die Abtasttheorie [440], dass ein zeitkontinuierliches Signal z(t) aus einer Folge 
y(t) analoger Werte erzeugt werden kann. 

Seien {t,},5 = ...,-1,0,1,2,... die Abtastzeitpunkte des Eingangssignals. Wir 
nehmen eine konstante Abtastrate von fs = r (Vs : Ts = ts+1 — ts) an. Die Abtast- 
theorie beschreibt die Approximation z(t) von e(t) mit Hilfe von y(t) wie folgt: 


S V(ts)sing (t — ts) 
z(t) = —; (3.29) 
Py q(t ~ ts) 
Diese Gleichung heißt Shannon-Whittaker-Interpolation. y(t) ist der Anteil des 
Signals y zum Abtastzeitpunkt ts. Der Einfluss dieses Anteils sinkt umso stärker, 
je weiter t von ts entfernt ist. Dabei wird diese Absenkung durch die sogenannte 
sinc-Funktion gewichtet: 


sin E(t ~ 1) 


an) (3.30) 
Ts 2 


sinc(t — ts) = 


16 Die Rekonstruktion mag möglich sein, wenn zusätzliche Informationen über das Signal vorliegen, 
z.B. wenn wir nur bestimmte Signaltypen betrachten. 
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Sie sinkt nicht monoton als eine Funktion von |t — t,|. Dieser Gewichtungsfaktor 
wird verwendet, um Werte zwischen den Abtastzeitpunkten zu berechnen. Abb. 3.53 
zeigt den Gewichtungsfaktor für den Fall T; = 1. 
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Abb. 3.53 Visualisierung der für die Interpolation verwendeten Gl. (3.30) 


Mit der sinc-Funktion können wir die einzelnen Terme der Summe aus Abb. 
3.29 berechnen. Abb. 3.54 und Abb. 3.55 zeigen die sich ergebenden Terme, wenn 
e(t) = e3(t) und die Verarbeitung der Daten diese unverändert lässt (x(t) = w(t)). 
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Abb. 3.54 y’(r) (rot) und die ersten drei Terme von Gl. (3.29) 


Zu jedem Abtastzeitpunkt t, (in unserem Fall nimmt t, nur ganzzahlige Werte an) 
wird z(t, ) nur aus dem entsprechenden Wert y(t,) berechnet, da die sinc-Funktion in 
diesem Fall für alle anderen abgetasteten Werte den Wert Null annimmt. Zwischen 
den Abtastzeitpunkten tragen alle benachbarten diskreten Werte zum sich ergebenden 
Wert von z(t) bei. Abb. 3.56 zeigt die sich ergebende Funktion z(t), wenn e(t) = e3(t) 
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Abb. 3.55 y’(r) (rot) und die letzten drei Terme von Gl. (3.29) 


und die Verarbeitung der Daten wieder die Identitätsfunktion (x(t) = w(t)) ausführt. 
Diese Abbildung beinhaltet die Signale e3(t) (blau), y’(t) (rot) und z(t) (magenta). 
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Abb. 3.56 e3(t) (blau), y’(t) (rot) und z(t) (magenta) 


œ 


z(t) entsteht, indem die Anteile aller Abtastzeitpunkte aus den Diagrammen 3.54 
und 3.55 summiert werden. e3(t) und z(t) sind sehr ähnlich. 

Wie nahe könnten wir nun dem Ausgangssignal kommen, wenn wir Glei- 
chung (3.29) implementieren? Die Abtasttheorie besagt (siehe z.B. [440]), dass 
Gleichung (3.29) eine exakte Approximation berechnet, wenn das Abtastkrite- 
rium eingehalten wird. Daher schauen wir uns nun an, wie wir die Gleichung (3.29) 
implementieren können. 

Wie berechnen wir Gleichung (3.29) in einem elektronischen System? Mit einem 
digitalen Signalprozessor können wir diese Gleichung nicht über einem diskreten 
Zeitbereich berechnen, da diese Berechnung ein in der Zeit kontinuierliches Signal 
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erzeugen muss. Zunächst scheint die Berechnung einer solch komplexen Gleichung 
mit analogen Schaltungen schwierig zu sein. 

Glücklicherweise ist die benötigte Berechnung eine sogenannte Faltungsoperati- 
on zwischen dem Signal y(t) und der sinc-Funktion. Nach der klassischen Theorie 
der Fouriertransformationen entspricht eine Faltungsoperation im Zeitbereich einer 
Multiplikation mit einer zeitabhängigen Filterfunktion im Frequenzbereich. Diese 
Filterfunktion ist die Fourier-Transformierte der entsprechenden Funktion über den 
Zeitbereich. Daher lässt sich Gleichung (3.29) mit einem passenden Filter berechnen. 
Abb. 3.57 zeigt die Lage des Filters. 
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Abb. 3.57 Konvertierung des Signals e(t) aus analogen Zeit- und Wertebereichen in digitale 
Bereiche und zurück 


Nun bleibt noch die Frage zu beantworten, welche frequenzabhängige Filterfunk- 
tion die Fourier-Transformierte der sinc-Funktion ist. Die Berechnung der Fourier- 
Transformierten der sinc-Funktion ergibt eine Tiefpass-Filterfunktion [440]. Also 
müssen wir „nur” das Signal y(t) mit einem Tiefpassfilter bearbeiten, um die Glei- 
chung (3.29) zu berechnen. Damit filtern wir Frequenzen, wie es für den „idealen 
Filter” von Abb. 3.58 gezeigt ist. Hier fällt auf, dass die Darstellung der Funktion y(t) 
als Summe von Sinuswellen einige sehr hohe Frequenzkomponenten benötigen wür- 
de. Daher entfernt eine solche Filterung Signalanteile mit sehr hohen Frequenzen, 
obwohl wir bereits einen Anti-Aliasing-Filter am Eingang vorgesehen hatten. 


Abb. 3.58 Tiefpassfilter: Amplitudengang 
ideal (blau, gestrichelt) und 
real (rot, durchgezogene Linie) 


| idealer Filter 


realisier- 
barer Filter 


Es gibt noch ein weiteres Problem: ideale Tiefpassfilter existieren nicht. Daher 
müssen wir Kompromisse eingehen und Filter entwerfen, welche die Eigenschaf- 
ten eines Tiefpassfilters annähern. Genau genommen müssen wir mit verschiedenen 
Unvollkommenheiten zurecht kommen, die eine präzise Rekonstruktion des Ein- 
gangssignals verhindern: 
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e Ideale Tiefpassfilter lassen sich nicht realisieren. Daher müssen wir Näherungen 
solcher Filter verwenden. Der Entwurf guter Kompromisse ist eine Kunst, die 
z.B. bei Audiogeräten weit verbreitet ist. 

e Aus demselben Grund können wir Eingangsfrequenzen oberhalb der Nyquist- 
Frequenz nicht vollständig ausfiltern. 

e Der Einfluss der Wertequantisierung wird in Abb. 3.56 deutlich. Durch die Wer- 
tequantisierung ist e3(f) manchmal verschieden von z(t). Das von A/D-Wandlern 
eingebrachte Quantisierungsrauschen kann während der Erzeugung der Ausgabe 
nicht entfernt werden. Das Signal w(t) am Ausgang des A/D-Wandlers wird daher 
durch das Quantisierungsrauschen gestört sein. Dieser Effekt betrifft allerdings 
nicht das Signal h(t) am Ausgang von Sample-and-hold-Schaltungen. 

e Gleichung (3.29) verwendet eine unendliche Summe, die auch Werte an zukünf- 
tigen Zeitpunkten beinhaltet. In der Praxis lassen sich Signale um eine endliche 
Zeit verzögern, um eine endliche Anzahl „zukünftiger” Werte zu erhalten. Un- 
endliche Verzögerungen sind unmöglich. In Abb. 3.56 haben wir die Beiträge von 
Abtastzeitpunkten außerhalb des Diagramms nicht berücksichtigt. 


Die Funktionalität der Tiefpassfilter zeigt die Leistungsfähigkeit analoger Schal- 
tungen: es wäre im digitalen Bereich nicht möglich, das Verhalten analoger Filter zu 
implementieren, da die diskretisierten Zeit- und Wertebereiche hier Einschränkun- 
gen erfordern. 

Viele Autoren waren an der Entwicklung der Abtasttheorie beteiligt. Damit sind 
auch viele Namen mit dem Abtasttheorem verbunden. Zu den wichtigsten Namen 
zählen Shannon, Whittaker, Kotelnikov, Nyquist und Küpfmüller. Daher sollte die 
Tatsache, dass ein Ursprungssignal rekonstruiert werden kann, einfach „Abtasttheo- 
rem” genannt werden, da es unmöglich ist, das Theorem nach allen beteiligten 
Wissenschaftlern zu benennen. 


3.6.3 Pulsbreitenmodulation 


In der Praxis besitzt die beschriebene Erzeugung von Analogsignalen einige Nach- 
teile: 


e Die Realisierung von D/A-Wandlern mit einer Menge von Widerständen ist 
schwierig. Die Genauigkeit der Widerstände muss exzellent sein. Die Abwei- 
chung des Widerstandes für das signifikanteste Bit von seinem nominellen Wert 
muss kleiner sein als die Auflösung des Wandlers. Beispielsweise muss die Ab- 
weichung bei einem 14-Bit-Wandler kleiner als 0,01% sein. Diese Genauigkeit 
ist schwer zu erreichen, insbesondere über den vollständigen Temperaturbereich. 
Wenn diese Genauigkeit nicht erreicht wird, ist der Wandler nicht linear, mögli- 
cherweise noch nicht einmal monoton. 

e Es werden analoge Leistungsverstärker benötigt, um ausreichend Leistung für 
Motoren, Lampen, Lautsprecher usw. zu erzeugen. Analoge Leistungsverstärker, 
insbesondere die sogenannten Klasse-A Verstärker, sind sehr energieineffizient, 
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denn sie enthalten einen immer leitenden Pfad zwischen den beiden Anschlüssen 
der Betriebsspannung. Dieser Pfad bewirkt eine ständige Leistungsaufnahme, un- 
abhängig vom Ausgabesignal. Das Verhältnis zwischen der tatsächlich genutzten 
(Wechselstrom-) Leistung und der verbrauchten elektrischen Leistung wäre da- 
her sehr klein. Insgesamt betrachtet wäre die Effizienz von Audioverstärkern für 
kleine Lautstärken entsetzlich schlecht. 

e Analoge Schaltkreise können auf ansonsten digitalen Chips nicht so einfach in- 
tegriert werden. Externe analoge Komponenten würden die Kosten sehr in die 
Höhe treiben. 


Daher ist die Pulsbreitenmodulation (engl. pulse 


width modulation (PWM)) sehr populär. Mit PWM we 

starten wir mit einem digitalen Wert und generie- a | 

ren ein digitales Rechtecksignal, dessen Tastverhältnis | 75% 

dem zu wandelnden Wert entspricht. Abb. 3.59 zeigt == 
t 


digitale Signale mit Tastverhältnissen von 25% und 
75%. Solche Signale können durch Fourierreihen wie Abb. 3.59 Tastverhältnisse 
in Gleichung (3.1) dargestellt werden. Für die Anwen- 
dung von PWM versuchen wir, die Effekte höherer Frequenzen zu eliminieren. 


PWM-Signale können erzeugt Programmierbarei =e 
werden, indem wir einen Zähler Takt => Zähler 
mit einem Wert vergleichen, der in 

einem programmierbaren Register | -Register 0 oe 
gespeichert ist (siehe Abb. 3.60). 
Eine hohe Spannung wird immer 
erzeugt, wenn der Wert im Zähler 
den Wert im Register übersteigt. 
Sonst wird eine Spannung nahe 
Null generiert. Das Taktsignal des 
Zählers muss programmierbar sein, 
damit die Basisfrequenz der PWM- Abb. 3.60 Hardware für PWM-Ausgabe 

Signale gewählt werden kann. In 

unserer Schaltung haben wir angenommen, dass die PWM-Frequenz für alle Ausgän- 
ge gleich ist. Die Register müssen mit den Werten geladen werden, die zu wandeln 
sind, typischerweise entsprechend der Abtastrate der Analogsignale. 

Der Aufwand für die Filterung der höheren Frequenzanteile hängt von der An- 
wendung ab. Im Fall eines Motors geschieht eine entsprechende Mittelwertbildung 
im Motor selbst, da die sich bewegenden Teile eine gewisse Masse haben und da 
in der Regel Induktivitäten im Motor ebenfalls filternd wirken. Aus diesem Grund 
werden keine externen Komponenten benötigt (siehe Abb. 3.60). Im Falle von Lam- 
pen erfolgt die Mittelwertbildung im menschlichen Auge, solange die Frequenzen 
nicht zu niedrig sind. Einfache Klingeln kann man auch direkt antreiben. In anderen 
Fällen kann das Filtern von hohen Frequenzanteilen erforderlich sein. So kann die 
elektromagnetische Strahlung durch hohe Frequenzanteile Störungen bewirken und 
Audioanwendungen können ebenfalls eine Filterung verlangen. In Abb. 3.60 wurden 
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+> Register 2 4 > it 


L 
t-> Register | 


Mikrocontroller-Bus 


206 3 Hardware eingebetteter Systeme 


zwei Kondensatoren und eine Spule zur Filterung von hohen Frequenzanteilen vor- 
gesehen. In unserem Beispiel gibt es vier PWM-Ausgänge. Es ist üblich, mehrere 
PWM-Ausgänge zu haben. Atmel 32-Bit AVR Microcontroller in der AT32UC3A- 
Serie haben beispielsweise sieben PWM-Ausgänge [26]. In der Praxis gibt es viele 
Optionen für das detaillierte Verhalten von PWM-Hardware. 

Kompromisse sind erforderlich für die Wahl der Basisfrequenz (dem Rezipro- 
ken der Periode) des PWM-Signals und des Filters. Die Basisfrequenz muss größer 
sein als der höchste Frequenzanteil im zu konvertierenden Signal. Höhere Basisfre- 
quenzen machen den Entwurf des Filters — sofern erforderlich — einfacher. Zu hohe 
Basisfrequenzen erzeugen allerdings mehr elektromagnetische Störungen und einen 
hohen Energiebedarf, da jedes Schalten Energie verbrauchen wird. Typischerweise 
benutzt man Basisfrequenzen, die zwischen einem Faktor 2 und 10 größer sind als 
die größte Frequenz des zu wandelnden Signals. 


3.6.4 Aktuatoren 


Es gibt eine Vielzahl von Aktuatoren [151], von riesigen Aktuatoren, die in der Lage 
sind, Gewichte von mehreren Tonnen zu bewegen, bis hin zu winzigen Aktuatoren 
mit einer Größe im um-Bereich. 

Als Beispiel nennen wir hier eine bestimmte Art von Aktuatoren, die zukünftig an 
Bedeutung gewinnen werden: die Mikrosystemtechnologie erlaubt die Herstellung 
von winzigen Aktuatoren, die beispielsweise in den menschlichen Körper einge- 
pflanzt werden können. Mit Hilfe solcher Miniaktuatoren kann die Menge von Me- 
dikamenten, die in den Körper eingebracht werden, genau an den aktuellen Bedarf 
angepasst werden. Damit ist eine viel bessere Medikamentenversorgung möglich als 
mit herkömmlichen Injektionen. 


Beispiel 3.19: Abb. 3.61 zeigt einen Miniaturmotor, der mit Mikrosystemtechnolo- 
gie hergestellt wurde. Seine Größe bewegt sich im um-Bereich. Der drehbare Teil in 
der Mitte wird durch dreiphasige elektrostatische Kräfte gesteuert [478]. V 


Aktuatoren sind für das Internet der Dinge wichtig. Es ist unmöglich, einen 
Überblick über alle verfügbaren Aktuatoren zu geben. 


3.7 Elektrische Energie 


Die allgemeinen Randbedingungen und Ziele für den Entwurf von eingebetteten und 
cyber-physikalischen Sytemen (siehe Seiten 9 bis 18 und Tabelle 1.2) müssen auch 
für den Entwurf von Hardware eingehalten werden. Unter den verschiedenen Zielen 
konzentrieren wir uns auf jene, welche elektrische Energie betreffen. Gründe hierfür 
sind in Tabelle1.1 auf Seite 15 angegeben. 
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Abb. 3.61 Detail eines rotierenden Schrittmotors; oben: fester Teil, unten: beweglicher Teil; © 
Sarajlic et al. [478] 


3.7.1 Energieerzeugung 


Bei Geräten, die mit den Stromnetz verbunden sind, ist elektrische Energie relativ 
leicht verfügbar. Bei allen anderen Geräten muss die Energie mit anderen Techniken 
bereit gestellt werden. Insbesondere trifft dieses auf Sensornetzwerke zu, wo die 
Energie eine besonders knappe Ressource ist. 

Batterien speichern Energie in Form von chemischer Energie. Ihre wesentliche 
Einschränkung ist, dass sie dorthin getragen werden müssen, wo die Energie ge- 
braucht wird. Wenn wir diese Einschränkung vermeiden wollen, dann müssen wir 
Energie „ernten” (im Englischen als energy harvesting oder energy scavenging be- 
zeichnet). Es gibt sehr viele Techniken, Energie zu ernten [575, 569], aber die Menge 
an erreichbarer Energie ist typischerweise sehr begrenzt: 


e Photovoltaik ermöglicht die Umwandlung von Licht in elektrische Energie. Die 
Umwandlung basiert üblicherweise auf dem photovoltaischen Effekt von Halb- 
leitern. Abb. 3.62 zeigt Beispiele. 

e Der piezoelektrische Effekt kann benutzt werden, um mechanische Verformung 
in elektrische Energie zu wandeln. Piezoelektrische Zünder nutzen diesen Effekt. 

e Thermoelektrische Generatoren (TEGs) erzeugen elektrische Energie beim 
Vorliegen von Temperaturgradienten. Mitihnen kann z.B. die Wärme des mensch- 
lichen Körpers für die Energieerzeugung genutzt werden. 
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Abb. 3.62 Photovoltaisches Material: links: Solarmodul; rechts: Solaruhr 


e Kinetische Energie kann in elektrische Energie gewandelt werden. Dies wird 
beispielsweise bei manchen Armbanduhren ausgenutzt. 

« Elektromagnetische Strahlung kann ebenfalls in elektrische Energie gewandelt 
werden. 

e Viele weitere physikalische Effekte erlauben die Konversion anderer Formen von 
Energie in elektrische Energie. 


3.7.2 Energiespeicherung 


In vielen Anwendungen eingebetteter Systeme ist keine permanente Versorgung mit 
Energie garantiert. Es kann aber möglich sein, Energie zu speichern. Beispielsweise 
gibt es folgende Methoden der Energiespeicherung: 


1. Nicht wiederaufladbare Batterien können nur einmal benutzt werden und werden 
nicht weiter betrachtet. 

2. Kondensatoren sind eine bequeme Möglichkeit, elektrische Energie zu speichern. 
Sie lassen sich extrem schnell aufladen, bieten sehr hohe Ausgangsströme, sind 
fast frei von Verlusten und lassen sich sehr häufig aufladen. Leider speichern 
sie nur eine begrenzte Menge an Energie, wobei mit Superkondensatoren (engl. 
supercaps) durchaus erhebliche Mengen an Energie gespeichert werden können. 

3. Wiederaufladbare Batterien können wie Kondensatoren Energie speichern, aller- 
dings in der Regel mit einer geringeren Zahl von Ladezyklen. Die Speicherung 
basiert auf chemischen Prozessen und die Entladung basiert auf der Umkehrung 
dieser Prozesse. 


Aufgrund ihrer Bedeutung für eingebettete Systeme betrachten wir hier wie- 
deraufladbare Batterien. Wenn wir Quellen von Energie in unserem Systemmodell 
einschließen wollen, dann benötigen wir Modelle von wiederaufladbaren Batterien. 
Verschiedene Modelle können benutzt werden. Sie unterscheiden sich im Umfang der 
eingeschlossenen Details und es gibt nicht das eine Modell, das alle Anforderungen 
erfüllt [467]. Die folgenden Modelle werden häufig benutzt: 
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Chemische und physikalische Modelle: diese beschreiben die chemischen oder 
physikalischen Vorgänge im Detail. Solche Modelle können Differentialgleichun- 
gen mit vielen Parametern beinhalten. Diese Modelle sind für die Hersteller von 
Batterien gut geeignet, aber für Designer von eingebetteten Systemen, die in der 
Regel diese Parameter nicht kennen, typischerweise zu komplex. 

Einfache empirische Modelle: solche Modelle basieren auf einfachen Gleichun- 
gen, deren Parameterwerte bestimmt wurden. Das Gesetz von Peukert [451] ist 
ein beliebtes Modell. Danach berechnet sich die Lebensdauer einer Batterie zu: 


Lebensdauer = C/I” (3.31) 


wobei a > 1 das Ergebnis einer empirischen Anpassung ist. Das Gesetz von 
Peukert spiegelt wider, dass hohe Ströme typischerweise zu einer Verkürzung der 
Batterielebensdauer führen. Andere Details des Verhaltens von Batterien sind in 
diesem Modell nicht enthalten. 

Abstrakte Modelle modellieren mehr Details als die einfachen empirische Mo- 
dell, aber gehen nicht auf die Ebene der chemischen Prozesse. Wir werden zwei 
solcher Modelle präsentieren: 


— Das elektrische Model von Chen and Ricön [96], das in Abb. 3.63 zu sehen ist. 
Nach diesem Modell steuert ein Ladestrom Jgq;; eine Stromquelle im linken 
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Abb. 3.63 Batteriemodell von Chen et al. (vereinfacht) 


Teil des Schaltplans. Der von der Stromquelle erzeugte Strom ist gleich dem 
von rechts hereinkommenden Ladestrom. Dieser Strom lädt den Kondensator 
Ccapacity. Die jeweilige Ladung Q auf dem Kondensator wird State of Char- 
ge (SoC) genannt. Diese Ladung spiegelt sich in der Spannung Vsoc über 
den Anschlüssen des Kondensators wider, da für die Ladung Q die Konden- 
satorgleichung Q = Ccapacity * Vsoc gilt. Der Widerstand Rseif-Discharge 
modelliert die Selbstentladung des Kondensators, die selbst dann stattfindet, 
wenn kein Strom über die Anschlüsse des Kondensators abfließt. 

Als nächstes betrachten wir die Spannung an den Anschlüssen des Kondensa- 
tors, wenn der Strom durch diese Anschlüsse Null ist (die sogenannte Leer- 
laufspannung (engl. open terminal output voltage)). Die Spannung an den 
Anschlüssen wird typischerweise nichtlinear von Vsoc abhängen. Diese Ab- 
hängigkeit kann durch eine nichtlineare Funktion Voc(Vsoc) modelliert wer- 
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den. Voc nimmt mit steigendem Ausgangsstrom ab. Fiir einen konstanten Ent- 
ladestrom modelliert die Reihenschaltung Rseries + Rrransient_s den entspre- 
chenden Spannungsverlust. Für kurze Stromspitzen ist ausschließlich Rseries 
relevant, da solche Spitzen durch Cr gepuffert werden. Für längere Entlade- 
phasen bestimmt die Zeitkonstante Rryansient_s * Cr die Geschwindigkeit des 
Übergangs von dem Spannungsabfall über Rseries zum Spannungsabfall über 
Rseries + Rrransient_s. Der ursprüngliche Vorschlag von Chen et al. enthält 
ein zweites Widerstand/Kondensator-Paar, um das Verhalten bei Entladepha- 
sen genauer zu modellieren. Insgesamt beschreibt dieses Modell die Wirkung 
von hohen Entladeströmen auf die Ausgangsspannung, die Selbstentladung 
und die nichtlineare Abhängigkeit der Ausgangsspannung vom Ladezustand 
relativ gut. Einfachere Varianten dieses Modell existieren, sind aber nicht in 
der Lage, alle drei Effekte zu beschreiben. 

Gebräuchliche Batterien besitzen einen Erholungseffekt: wenn der Entladevor- 
gang für eine Weile unterbrochen wird, wird zusätzliche Ladung verfügbar und 
die Spannung steigt meist auch wieder an. Dieser Effekt wird in Chens Modell 
nicht erfasst. Erfasst wird er im kinematischen Batteriemodell (KiBaM) von 
Manwell et al. [365]. Die Bezeichnung spiegelt die Analogie wieder, auf der es 
basiert. Im Modell gehen wir von zwei Behältern mit Ladung aus, wie in Abb. 
3.64 gezeigt. Der rechte Behälter enthält eine Ladung yı, die sofort verfügbar 
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Abb. 3.64 Kinematisches Batteriemodell 


ist. Der linke Behälter enthält eine Ladung y2, die in der Batterie existiert, die 
aber in den rechten Behälter fließen muss, bevor sie genutzt werden kann. Eine 
Phase hoher Entladeströme könnte den rechten Behälter fast vollständig entlee- 
ren. Es dauert dann eine Weile, bevor wieder mehr Ladung zur Verfügung steht. 
Die Geschwindigkeit der Erholung wird durch den Parameter k bestimmt, der 
im mechanischen Modell dem Durchmesser des Rohrs entspricht, welches bei- 
de Behälter verbindet. Der elektrische Strom wird bei diesem Modell über die 
entsprechenden mechanischen Größen berechnet. Dieses Modell beschreibt 
die Erholung der Batterien mit einiger Genauigkeit, aber es kann Selbstent- 
ladung und das Verhalten bei Stromimpulsen im Gegensatz zu Chens Modell 
nicht erfassen. Darüber hinaus werden auch die Alterung oder temperaturab- 
hängige Effekte nicht modelliert. Aus dem kinematischen Modell heraus kann 
man bestimmen, wie man die gespeicherte Energie am besten nutzt. Beispiels- 
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weise wurde gezeigt, dass es sinnvoll ist, bei der drahtlosen Datenübertragung 
Intervalle vorzusehen, in denen die Übertragung abgeschaltet wird, weil sich 
so die Batterien erholen können [144]. 

Insgesamt zeigen die beiden Modelle, dass man Modelle wählen muss, welche 
die Effekte, die man berücksichtigen möchte, auch erfassen. 


« Es kann gemischte Modelle geben, die teils auf abstrakten und teils auf che- 
misch/physikalischen Modellen basieren. 


3.7.3 Effiziente Nutzung elektrischer Energie 


Energieeffizienz von Hardwareplattformen 


Die Hardwaretechnologien, welche in diesem Kapitel betrachtet wurden, unterschei- 
den sich hinsichtlich ihrer Energieeffizienz, wie in Abb. 3.65 zu sehen ist. 
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Abb. 3.65 Energieeffizienz (©De Man und Philips) 


Die Abbildung zeigt einen Vergleich der Energieeffizienz als Anzahl der Ope- 
rationen per Einheit der Energie (GOP/J) als Funktion der Hardwaretechnologie 
(ASICs, Prozessoren, FPGAs) und der Zeit, die jeweils ein Spiegelbild der ver- 
fügbaren Miniaturisierung in der Fertigungstechnologie ist!’. In diesem Kontext 


17 Die Abbildung ist eine Approximation von Informationen von H. De Man [364] und basiert auf 
Informationen von Philips. 
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verstehen wir unter Operationen beispielsweise 32-Bit Additionen. Offensichtlich 
können pro Joule immer mehr Operationen ausgeführt werden, da kleinere Struktur- 
größen in der Chipfertigung zu effizienteren Chips führen. Für ein festes Jahr und 
eine damit verfügbare Fertigungstechnologie ist aber die Energieeffizienz am höchs- 
ten für ASICs. Für rekonfigurierbare Schaltungen wie FPGAs (siehe Seite 181) ist 
die Effizienz ca. eine Größenordnung geringer. Für programmierbare Prozessoren ist 
sie noch geringer. Dagegen offerieren Prozessoren die größte Flexibilität hinsicht- 
lich ihrer Programmierbarkeit. Etwas Flexibilität gibt es auch noch für FPGAs, aber 
diese ist begrenzt auf die Größe von Anwendungen, die sich auf FPGAs abbilden 
lassen. Für ASICs gibt es keine Flexibilität. Ein Abwägen zwischen Flexibilität und 
Effizienz existiert selbst innerhalb der Klasse der Prozessoren: Prozessoren, die für 
einen bestimmten Anwendungsbereich optimiert sind, wie z.B. digitale Signalpro- 
zessoren, erreichen eine Effizienz nahe der von FPGAs. Für allgemeine Prozessoren 
ist die Effizienz am geringsten. Dies zeigt sich in Abb. 3.65 daran, dass die Effizi- 
enz von x86-ähnlichen Prozessoren (siehe „MPU”-Einträge) geringer ist als die von 
DSP-Prozessoren. 

Für Abb. 3.65 ist nicht genau bekannt, welche Anwendungen untersucht wurden 
und wie Anwendungen auf die Prozessoren abgebildet wurden. Jüngere und detail- 
liertere Publikationen erlauben es, diese Vergleiche umfassender zu gestalten. Eine 
Übersicht über Vergleiche, die auch GPUs einschließt, wurde von Mittal et al. pu- 
bliziert [399]. Die Übersicht enthält eine Liste von 28 Publikationen, denen zufolge 
GPUs in den jeweiligen Anwendungen energieeffizienter waren als CPUs sowie zwei 
Publikationen, in denen das Gegenteil gefunden wurde. Die Übersicht enthält auch 
eine Liste von 26 Publikationen, denen zufolge FPGAs energieeffizienter waren als 
GPUs und eine Publikation, die über das Gegenteil berichtet. Beispielsweise fanden 
Hamada et al. [201] für eine n-Körper-Simulation der Gravitation, dass mit FPGAs 
fünfzehn Mal mehr Operationen pro Watt ausgeführt werden konnten als mit GPUs. 
Verglichen mit CPUs betrug der Faktor sogar 34. Die genauen Faktoren hängen 
sicherlich von der Anwendung ab, aber als Daumenregel können wir folgendes fest- 
halten: Wenn wir auf Spitzenwerte für die Energie- und Leistungseflizienz zielen, 
sollten wir ASICs benutzen. Wir sollten FPGAs nehmen, wenn ASICs z.B. aus 
Kostengründen ausscheiden. Wir sollten GPUs nehmen, wenn FPGAs nicht in Frage 
kommen, weil z.B. Kompetenz zur Programmierung fehlt. Bei Prozessoren sind hete- 
rogene Prozessoren effizienter als homogene. Für abgegrenzte Anwendungsbereiche 
lassen sich weitere Informationen gewinnen. 


Mobiltelefone 


Als einen speziellen Anwendungsbereich von eingebetteten Systemen (siehe Seiten 
4 bis 9) betrachten wir nunmehr Telekommunikation und Mobiltelefone. Bei Mobil- 
telefonen steigen die Anforderungen an die Rechenleistung (Performanz) sehr stark 
an, v.a. für Multimediaanwendungen. De Man und Philips haben geschätzt, dass 
fortgeschrittene Multimediaanwendungen etwa 10 bis 100 Milliarden Operationen 
pro Sekunde benötigen. Abb. 3.65 zeigt, dass fortgeschrittene Hardwaretechnolo- 
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gien im Jahr 2007 etwa diese Anzahl von Operationen pro Joule (= Ws) bereit 
stellten. Mithin boten die effizientesten Hardwareplattformen so gerade eben die 
Effizienz, die benötigt wurde. Standardprozessoren (siehe Einträge für MPU und 
RISC) waren hoffnungslos ineflizient. Dies bedeutete auch, dass alle Möglichkeiten 
einer Steigerung der Energieeffizienz genutzt werden mussten. In den letzten Jahren 
wurde die Energieeffizienz verbessert. Allerdings wurden alle diese Verbesserungen 
wieder „aufgebraucht”, um eine bessere Qualität bereit zu stellen, z.B. durch eine 
Erhöhung der Auflösung von Fotos bzw. Videos sowie durch größere Bandbreiten 
bei der Kommunikation. 

Detaillierte Analysen des Leistungsverbrauchs wurden von Berkel [47] und von 
Carroll et al. [84] publiziert. Eine neuere Analyse, die auch Mobiltelefone mit 
LTE einbezieht, wurde von Dusza et al. [144] veröffentlicht. Es wurde eine Leis- 
tungsaufnahme von bis zu vier Watt beobachtet. Das Display war dabei für eine 
Leistungsaufnahme von bis zu einem Watt verantwortlich, je nach Displayhelligkeit. 

Eine bessere Batterietechnologie würde es uns erlauben, über längere Zeiträume 
mehr Leistung zu verbrauchen, aber aus thermischen Gründen können wir in der 
nächsten Zeit kaum über die aktuelle Leistungsaufnahme hinaus gehen. Zur Vermei- 
dung von Überhitzung ist es inzwischen Standard, Mobiltelefone mit Temperatursen- 
soren auszustatten und ggf. zu drosseln. Dabei könnten größere Mobiltelefone mehr 
Wärme an die Umwelt abgeben und somit auch eine größere Leistung verbrauchen. 
Die Leistungsaufnahme sollte aber aus Umweltschutzgründen nicht zu stark steigen. 

Technologievorhersagen wurden auch als sogenannte International Technology 
Roadmap for Semiconductors (ITRS) publiziert. In der ITRS Ausgabe von 2013 
[262] wird explizit bestätigt, dass Mobiltelefone die technologische Entwicklung 
vorantreiben: „System integration has shifted from a computational, PC-centric 
approach to a highly diversified mobile communication approach. The heterogeneous 
integration of multiple technologies in a limited space (e.g., GPS, phone, tablet, 
mobile phones, etc.) has truly revolutionized the semiconductor industry by shifting 
the main goal of any design from a performance driven approach to a reduced power 
driven approach. In few words, in the past performance was the one and only goal; 
today minimization of power consumption drives IC design”. 


Sensornetzwerke 


Sensornetzwerke, wie sie beim Internet der Dinge benutzt werden, sind ein zweiter 
Anwendungsfall. Bei Sensornetzwerken ist möglicherweise noch weniger elektri- 
sche Energie vorhanden als bei Mobiltelefonen. Daher ist die Energieeffizienz äußerst 
wichtig, einschließlich der Effizienz der Kommunikation [542]. 
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3.8 Sichere Hardware 


Die allgemeinen Anforderungen an eingebettete Systeme enthalten oft auch An- 
forderungen an die Informationssicherheit (siehe Seite 9). Insbesondere ist diese 
Sicherheit fiir das Internet der Dinge wichtig. Wenn Sicherheit einen hohen Stellen- 
wert hat, dann muss aus diesem Grund evtl. spezielle Hardware entwickelt werden. 
Sicherheit muss möglicherweise v.a. für die Kommunikation und die Speicherung 
gewährleistet sein [310]. Sicherheit kann i.d.R. nicht unter allen Umständen garan- 
tiert werden, sondern man muss sich tiberlegen, welche Angriffe oder Attacken 
möglich sind und jeweils für solche Angriffe Abwehrmaßnahmen bereit stellen. Es 
muss dann der Nachweis der Sicherheit trotz dieser Attacken garantiert werden. Man 
kann zwischen Angriffsklassen unterscheiden (in Anlehnung an Ravi et al. [301]): 


e Softwareangriffe basieren ausschließlich auf der Ausführung von Software. Die 
Entwicklung von Trojanischen Pferden ist ein Beispiel eines solchen Angriffs. 
Es können auch Fehler in der Software ausgenutzt werden. Pufferüberläufe sind 
eine häufige Ursache für eine Verletzlichkeit der Software. Ein spezieller Fall sind 
Seitenkanalangriffe, bei denen man versucht, Wege des Informationsflusses zu 
eröffnen, die im Entwurf eigentlich nicht vorgesehen waren. Seitenkanalangriffe 
auf Softwarebasis sind relativ schwierig zu realisieren. Allerdings sind beispiels- 
weise Seitenkanalangriffe durch Zeitanalyse möglich, wenn die Ausführungszeit 
von Software datenabhängig ist!®. Sicherheitsrelevante Algorithmen sollten so 
entworfen sein, dass die Ausführungszeit nicht von den Daten abhängt. Diese 
Anforderung berührt sogar die Realisierung von Rechnerarithmetik: Maschinen- 
befehle sollten keine datenabhängigen Ausführungszeiten haben. 

« Physikalische Angriffe sind i.d.R. ebenfalls Seitenkanalangriffe. Man kann sie 
folgendermaßen klassifizieren: 


— Physische Manipulationen: Beispielsweise kann man einen Siliziumchip öff- 
nen und analysieren. Der erste Schritt hierbei besteht daran, das Gehäuse zu 
entfernen. Als nächstes kann man den Chip optisch analysieren oder die Leiter- 
bahnen mit feinen Nadeln kontaktieren. Solche Angriffe sind schwierig, aber 
sie verraten viele Details der Chips. 

— Eine Analyse der Stromaufnahme bietet eine weitere Möglichkeit eines phy- 
sischen Seitenkanalangriffs. Die Analyse kann eine einfache Analyse (SPA) 
oder eine differentielle Analyse (DPA) umfassen. In manchen Fällen ist es 
möglich, Datenschlüssel durch eine einfache Analyse der Stromaufnahme her- 
auszufinden. In anderen Fällen können fortgeschrittene statistische Methoden 
benutzt werden, um Schlüssel aus kleinen statistischen Schwankungen der 
Stromaufnahme herauszufinden. 

— Eine Analyse der elektromagnetischen Strahlung bietet eine weitere Mög- 
lichkeit, physische Seitenkanäle zu eröffnen. 


18 Seitenkanal-Angriffe unter Ausnutzung von Zeitinformationen wurden unter den Namen Spec- 
tre und Meltdown sehr bekannt, da v.a. moderne Prozessoren mit spekulativer Ausführung davon 
betroffen sind, siehe u.a. https://de.wikipedia.org/wiki/Spectre_(Sicherheitslücke). 
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Die Angriffe konnen von verschiedenen Klassen von Personen versucht werden 
und wiederum unterschiedliche Klassen von Personen können ein Interesse daran 
haben, diese Angriffe zu verhindern. Beispielsweise können Angriffe durch reguläre 
Benutzer gestartet werden, die unberechtigten Zugriff auf ein Netzwerk oder eine 
geschützte Mediendatei haben möchten. 

Wir können zwischen den folgenden Gegenmaßnahmen unterscheiden: 


¢ Bei der Softwareentwicklung muss man sich der Sicherheitsrisiken bewusst sein, 
um Gegenmaßnahmen gegen Angriffe ergreifen zu können. 

e Mit physischen Mitteln wie einer Abschirmung oder Sensoren, die Manipulati- 
onsversuche erkennen, können Geräte geschützt werden. 

e Geräte können so entwickelt werden, dass Datenmuster einen möglichst geringen 
Einfluss auf die Stromaufnahme haben. Hierfür sind teilweise spezielle Schaltun- 
gen erforderlich, wie sie meistens in komplexen Chips nicht eingesetzt werden. 

e Logische Sicherheit, die i.d.R. mit kryptographischen Methoden erreicht wird: 
diese basieren entweder auf symmetrischen oder auf asymmetrischen Codes. 


— Bei symmetrischen Codes benutzen Sender und Empfänger denselben Schlüs- 
sel, um Nachrichten zu ver- und entschlüsseln. 

— Beiasymmetrischen Codes werden Nachrichten mit einem öffentlichen Schlüs- 
sel verschlüsselt und mit einem privaten Schlüssel entschlüsselt. So sind RSA- 
und Diffie-Hellman-Verschlüsselung asymmetrische Verschlüsselungen. 

— Werden Nachrichten Hash Codes zugefügt, so können Modifikationen der 
Nachricht erkannt werden. 


Aufgrund der begrenzten Performanz von Prozessoren in eingebetteten Systemen 
gibt es teilweise spezielle Maschinenbefehle zur Verschlüsselung und Entschlüs- 
selung, welche die Effizienz steigern. Es gibt auch spezialisierte Lösungen wie 
die TrustZone von ARM. „Ar the heart ofthe TrustZone approach is the concept 
of secure and non-secure worlds that are hardware separated, with non-secure 
software blocked from accessing secure resources directly. Within the processor, 
software either resides in the secure world or the non-secure world; a switch 
between these two worlds is accomplished via software referred to as the secu- 
re monitor (Cortex-A) or by the core logic (Cortex-M). This concept of secure 
(trusted) and non-secure (non-trusted) worlds extends beyond the processor to 
encompass memory, software, bus transactions, interrupts and peripherals within 
an SoC” (siehe https://www.arm.com/products/security-on-arm/trustzone). 

Der Kalray MPPA2®-256 Mehrkern-Prozessor-Chip enthält 128 Krypto-Copro- 
zessoren, die mit einer Matrix von „regulären” 64-Bit VLIW-Kernen verbunden 
sind (siehe http://www.kalrayinc.com/kalray/products/). 


Beim Entwurf von Gegenmaßnahmen gibt es Herausforderungen [301]: 


1. Die Performanzlücke: aufgrund der begrenzten Performanz von eingebette- 
ten Systemen sind fortgeschrittene Verschlüsselungstechniken möglicherweise 
zu langsam, v.a. wenn hohe Datenraten verarbeitet werden sollen. 
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2. Die Energielücke: fortgeschrittene Verschlüsselungstechniken benötigen eine 
große Menge an Energie. Diese große Menge ist in einem mobilen System mögli- 
cherweise nicht vorhanden. Insbesondere müssen smart cards mit einer besonders 
geringen Menge an Energie auskommen. 

3. Mangelnde Flexibilität: häufig sind viele verschiedene Sicherheitsprotokolle in 
einem System erforderlich und diese Protokolle müssen von Zeit zu Zeit aktuali- 
siert werden. Dies erschwert die Benutzung von speziellen Hardwarebeschleuni- 
gern für die Verschlüsselung. 

4. Manipulationsschutz: es ist nicht einfach, Maßnahmen gegen Angriffe von au- 
Ben einzubauen. Beispielsweise kann es schwierig sein, eine Stromaufnahme zu 
garantieren, die unabhängig von dem verarbeiteten Schlüssel ist. 

5. Verifikationslücke: eine Überprüfung der Sicherheitsmaßnahmen erfordert einen 
zusätzlichen Aufwand bei Entwurf und Herstellung, 

6. Kosten: Sicherheitsmaßnahmen erhöhen die Kosten von Systemen. 


Ravi et al. haben diese Herausforderungen für ein Secure Socket Layer (SSL) Proto- 
koll im Detail analysiert [301]. 

Weitere Informationen zu sicherer Hardware kann man beispielsweise in einem 
Buch von Gebotys [180] und in Tagungsbänden einer Serie von Workshops finden, 
die sich mit diesem Thema beschäftigen (siehe z.B. [183]). 


3.9 Aufgaben 


Die folgenden Aufgaben sollten entweder zu Hause oder während einer Anwesen- 
heitsphase nach dem flipped classroom-Konzept [376] bearbeitet werden: 


3.1: Lokal verfügbare kleine Roboter sollten benutzt werden, um die Komponenten 
in einer Regelschleife wie in Abb. 3.2 kennenzulernen. Diese Roboter sollten Sen- 
soren und Aktuatoren enthalten und sie sollten ein Programm ausführen, das eine 
Regelschleife realisiert. Beispielsweise kann ein optischer Sensor genutzt werden, 
um einen Roboter einer schwarzen Linie auf dem Boden folgen zu lassen. Die Details 
dieser Aufgabe hängen von der Verfügbarkeit von Robotern ab. 


3.2: Was ist ein „Signal”? 


3.3: Mit welchem Schaltkreistyp kann der Übergang von einer kontinuierlichen zu 
einer diskreten Zeit bewerkstelligt werden? 


3.4: Was ist der Inhalt des Abtasttheorems? 


3.5: Angenommen, wir haben ein Eingangssignal x, das aus einer Summe von 
Sinussignalen mit einer Frequenz von 1,75kHz und 2kHz besteht. Wir tasten x 
mit einer Rate von 3kHz ab. Können wir aus den Abtastwerten das Originalsignal 
rekonstruieren? Erklären Sie Ihr Ergebnis! 
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3.6: Der Übergang auf diskrete Werte basiert auf Analog/Digital- (A/D-) Wandlern. 
Entwickeln Sie einen Flash-A/D-Wandler für positive und negative Eingangsspan- 
nungen! Die Ausgabewerte sollten als 3-Bit-Zweierkomplementzahlen kodiert sein, 
sodass wir zwischen acht verschiedenen Spannungsbereichen unterscheiden können. 


3.7: Angenommen, wir arbeiten mit einem 4-Bit-A/D-Wandler nach dem Wäge- 
prinzip. Der Eingangsspannungsbereich reicht von Vmin =1 V (="0000") bis Vmax 
=4,75 V (="1111"). Welche Schritte werden benötigt, um Spannungen von 2,25 V, 
3,75 V und 18 V zu wandeln? Zeichnen Sie ein Diagramm wie in Abb. 3.12, welches 
die sukzessive Approximation an diese Spannungen zeigt! 


3.8: Vergleichen Sie den Flash-basierten Wandler mit dem Wandler nach dem Wä- 
geprinzip. Nehmen Sie an, Sie möchten zwischen n verschiedenen Spannungsinter- 
vallen unterscheiden. Tragen Sie die jeweilige Komplexität in die Tabelle 3.2 mit der 
O-Notation ein. 


Tabelle 3.2 Komplexität von A/D-Wandlern 


Flash-Konverter |Konverter nach dem Wägeprinzip 


Zeitkomplexität 


Hardwarekomplexität | 


3.9: Angenommen, wir legen ein Sinussignal an den Eingang des Konverters aus 
Aufgabe 3.6 an. Zeichnen Sie den Verlauf des Quantisierungsrauschens für diesen 
Fall! 


3.10: Welches sind typische Eigenschaften von DSP-Prozessoren? 


3.11: Welche Komponenten einhält ein FPGA (Beispiel: Xilinx-FPGAs)? Welche 
Komponenten werden benutzt, um Boolesche Funktion zu realisieren? Wie werden 
FPGAs konfiguriert? Sind FPGAs energieeffizient? Für welche Anwendungen sind 
FPGAs gut? 


3.12: Was ist die Grundidee von VLIW-Prozessoren? 


3.13: Was ist eine ,, single-ISA heterogeneous multi-core architecture” ? Warum nutzt 
man solche Architekturen? 


3.14: Erläutern Sie die Begriffe „GPU” und „MPSoC”! 


3.15: Einige FPGAs unterstützen die Realisierung aller Booleschen Funktionen von 
sechs Variablen. Wie viele solcher Funktionen gibt es? Wir ignorieren dabei, dass 
sich einige Funktionen nur um die Umbenennung von Variablen unterscheiden. 


3.16: Im Zusammenhang mit Speichern sagen wir manchmal small is beautiful. 
Welchen Grund kann es dafür geben? 
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3.17: Einige Ebenen der Speicherhierarchie werden vor Programmierern versteckt. 
Warum sollten Programmierer sich trotzdem um die Existenz solcher Ebenen kiim- 
mern? 


3.18: Was ist ein Scratchpad-Speicher (SPM)? Wie können wir erreichen, dass ein 
Speicherobjekt in einem solchen Speicher abgelegt wird? 


3.19: Entwickeln Sie das folgende FlexRay" Cluster: Das Cluster besteht aus den 
fünf Knoten A, B, C, D und E. Alle Knoten sollen mit zwei Kanälen verbunden 
sein. Das Cluster benutzt eine Bus-Topologie. Die Knoten A, B und C führen eine 
sicherheitskritische Task aus und daher sollten ihre Anforderungen des Busses bei 
20 Macroticks garantiert sein. Das nachfolgende wird erwartet: 


e Laden Sie den levi FlexRay Simulator [495]! Entpacken Sie die zip-Datei und 
installieren Sie den Simulator! 

e Starten Sie den Simulator indem Sie leviFRP.jar ausführen! 

e Entwerfen Sie das Flexray-Cluster als Simulatormodell! 

e Konfigurieren Sie den Kommunikationszyklus so, dass die Knoten A, Bund C 
nach einer maximaler Verzögerung von 20 macroticks einen Buszugriff haben! 
Die Knoten D and E sollen nur das dynamische Segment nutzen. 

e Konfigurieren Sie die Busanforderungen! Knoten A soll in jedem Zyklus eine 
Nachricht senden. Die Knoten B and C senden bei jedem zweiten Zyklus eine 
Nachricht. Knoten D sendet in jedem Zyklus eine Nachricht der Länge von 2 
Mikrozyklen und Knoten E sendet in jedem zweiten Zyklus eine Nachricht der 
Länge 2 Minislots 

e Starten Sie die Visualisierung und prüfen Sie, ob die Busanforderungen von A, B 
und C garantiert werden. 

e Vertauschen Sie die Positionen von D und E! Welches Verhalten beobachten Sie? 


3.20: Entwickeln Sie den Schaltplan eines 3-Bit Digital/Analog-Wandlers! Der 
Wandler soll Bitvektoren x, die jeweils eine positive 3-Bit-Zahl darstellen, wan- 
deln können. Beweisen Sie, dass die Ausgangsspannung proportional zu dem durch 
x dargestellten Wert ist! Wie würden Sie die Schaltung modifizieren, wenn x Zwei- 
erkomplementzahlen darstellt? 


3.21: Der Schaltkreis in Abb. B.4 im Anhang B ist ein Verstärker, der die Eingangs- 
spannung V; verstärkt: 
Vout = Sclosed * Vı 


Berechnen Sie die Verstärkung g¢josea für die Schaltung in Abb. B.4 als Funktion 
von R und Rı! 


3.22: Wie unterscheiden sich verschiedene Hardwaretechnologien hinsichtlich ihrer 
Energieeffizienz? 


3.23: Die Energieeffizienz wird manchmal in Milliarden Operationen pro Sekunde 
und Watt gemessen. Wie unterscheidet sich dieses Maß von dem Maß, das in Abb. 
3.65 benutzt wurde? 
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3.24: Warum ist es so wichtig, eingebettete Systeme zu optimieren? Vergleichen Sie 
verschiedene Hardwaretechnologien in Bezug auf ihre Energieeffizienz! 


3.25: Angenommen, ein Mobiltelefon benutzt eine Lithiumbatterie mit einer Kapa- 
zität von 3200 mAh. Die nominelle Spannung ist 3,7 V. Wie lange würde es dauern, 
bis die Batterie leer ist, wenn wir konstant 1 W Leistung entnehmen? Alle sekundären 
Effekte (wie eine abnehmende Batteriespannung) sollen ignoriert werden. 


3.26: Warum ist es schwierig, Informationssicherheit bei eingebetteten Systemen zu 
gewährleisten? 


3.27: Was ist ein Seitenkanalangriff? Nennen Sie Beispiele! 


Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 Internatio- 
nal Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nut- 
zung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und For- 
mat erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, 
einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenom- 
men wurden. 

Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der 
genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes er- 
gibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht 
und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben 
aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers 
einzuholen. 
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Zur Bewältigung der Komplexität des Entwurfes von Anwendungen eingebetteter 
Systeme ist die Wiederverwendung von Komponenten ein wichtiges Hilfsmittel. 
Im Sinne einer plattformbasierten Entwurfsmethode (siehe Seite 322) ist neben 
vorhandener Hardware auch Software einzusetzen. Diese Komponenten beinhal- 
ten das Wissen früherer Entwicklungen und stellen sogenanntes geistiges Eigen- 
tum (engl. Intellectual Property (IP)) dar. Zu den wiederverwendbaren Standard- 
Softwarekomponenten zählen Komponenten der Systemsoftware wie eingebettete 
Betriebssysteme (engl. Operating Systems (OS)) und sogenannte Middleware. Im 
diesem Kapitel beschreiben wir zunächst allgemeine Anforderungen an Betriebs- 
systeme für eingebettete Systeme. Dazu gehören insbesondere die Echtzeitfähigkeit 
und die Adaptierbarkeit an die jeweilige Anwendung. Beim exklusiven Zugriff auf 
Ressourcen kann es zur Prioritätsumkehr kommen, die für Echtzeitsysteme schwere 
Probleme verursachen kann. Diese können mit Zugriffsprotokollen für diese Ressour- 
cen vermieden werden. Mit der Prioritätsvererbung, dem Priority Ceiling-Protokoll 
und dem Stack Resource-Protokoll stellen wir drei wichtige Protokolle vor. Ein ei- 
gener Abschnitt ist dem Echtzeitkern ERIKA gewidmet, der v.a. für Mikrocontroller 
gedacht ist. Ein weiterer Abschnitt ist den Anpassungen gewidmet, mit denen Linux 
in eingebetteten Systemen eingesetzt werden kann. Das Kapitel schließt mit Hinwei- 


‘S 
( N Spezifikation Entwurfsdatenbank (ann) 
wn 

D 

z V N V 
ue Abbildung von Test 

g 2 HW-Komponenten Anwendungen 

c= 

Tos Optimierung 

Systemsoftware Bm 
J (RTOS, ...) Bewertung & Validierung 


Abb. 4.1 Vereinfachter Entwurfsfluss 


© Der/die Autor(en) 2021 221 
P. Marwedel, Eingebettete Systeme, https://doi.org/10.1007/978-3-658-33437-6_4 


222 4 Systemsoftware 


sen auf weitere wiederverwendbare Softwarekomponenten, insbesondere Hardware 
Abstraction Layers (HALs), Kommunikationssoftware und Echtzeitdatenbanken. 
Mit der Beschreibung eingebetteter Betriebssysteme und von Middleware in diesem 
Kapitel entsprechen wir dem Entwurfsfluss (siehe auch Abb. 4.1). 


4.1 Eingebettete Betriebssysteme 


4.1.1 Allgemeine Anforderungen 


Mit Ausnahme sehr einfacher Systeme benötigen eingebettete Anwendungen ein 
geeignetes Betriebssystem für die Ein/Ausgabe, für das Scheduling (d.h. die Ablauf- 
planung) und das Umschalten zwischen der Ausführung verschiedener Codeobjekte. 
Durch das Umschalten, Kontextwechsel (engl. context switching) genannt, entsteht 
der Eindruck, dass jedes Codeobjekt einen eigenen Prozessor besitzt. Bei Codeob- 
jekten unterscheiden wir zwischen Prozessen und Threads. Zunächst definieren wir 
Prozesse: 


Definition 4.1 (in Anlehnung an Tanenbaum [525]): Ein Prozess ist ein Programm 
(oder ein Teil eines Programms) einschließlich aller zugehörigen Speicherinhalte. 


Weitere Informationen zu diesem Begriff können Kursen zu Betriebssystemen ent- 
nommen werden (siehe z.B. Roitzsch [472]). In diesem Kapitel werden wir den 
Begriff „Prozess” immer in dem hier definierten Sinn als ein Objekt innerhalb eines 
Betriebssystems (und nicht im Sinne von Prozessen in SDL, VHDL, Prozessnetz- 
werken oder dem Halbleiterfertigungsprozess) benutzen. 

Bei Systemen mit virtuellem Speicher! unterscheiden wir zwischen verschiede- 
nen Adressräumen. In solchen Systemen können wir differenzieren, ob verschiedene 
in Ausführung befindliche Codeobjekte jeweils in einem eigenen Adressraum aus- 
geführt werden oder ob sie sich einen Adressraum teilen; im ersten Fall sprechen wir 
von Prozessen, im zweiten Fall von Threads (deutsch: Fäden, auch leichtgewichtige 
Prozesse genannt). 


Definition 4.2: Ein Thread ist ein Programm in Ausführung, welches sich von einem 
Prozess durch die Verwendung eines gemeinsamen Adressraums unterscheidet. 


Im ersten Fall existiert ein gewisser Schutz der Objekte gegeneinander, da sich ver- 
schiedene Objekte nicht einfach den Speicher überschreiben können. Allerdings er- 
fordert der Kontextwechsel hier auch Aufwand für den Wechsel des Adressbereichs. 
Im zweiten Fall existiert dieser Schutz nicht, dafür ist der Kontextwechsel schneller 
und die Kommunikation über gemeinsamen Speicher (engl. shared memory) einfach 
realisierbar. In Systemen mit nur einem Adressraum entfällt die Unterscheidung 
zwischen Prozessen und Threads. Betriebssysteme müssen Kommunikations- und 
Synchronisationsmechanismen für Threads und Prozesse zur Verfügung stellen. 


! Siehe Anhang C. 
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Vertiefende Informationen über die hier angesprochenen Standardthemen im Sys- 
temsoftwarebereich finden sich in Betriebssystem-Lehrbüchern wie z.B. dem Buch 
von Tanenbaum [525]?. 

Die folgenden Eigenschaften sind für eingebettete Betriebssysteme wesentlich: 


e Die große Vielfalt eingebetteter Systeme resultiert in einer großen Vielfalt von 
Anforderungen an die Funktionalität eingebetteter Betriebssysteme. Aus Effizi- 
enzgründen ist es nicht möglich, ein System einzusetzen, das alle Eigenschaften 
zur Verfügung stellt. Die meisten Anwendungen benötigen ein kleines Betriebs- 
system. Daher sollten Betriebssysteme eine flexible Maßschneiderung auf die 
gegebene Anwendung zulassen. Konfigurierbarkeit ist daher eine der wichtigs- 
ten Eigenschaften eingebetteter Betriebssysteme. Konfigurierbarkeit lässt sich mit 
einer Reihe von Techniken realisieren, wie z.B.°: 


— Objektorientierung zur Ableitung geeigneter Unterklassen. Von einer all- 
gemeinen Scheduler-Klasse könnten z.B. Scheduler mit bestimmten Eigen- 
schaften abgeleitet werden. Allerdings erfordern objektorientierte Ansätze oft 
zusätzlichen Aufwand. So erzeugt zum Beispiel das dynamische Binden von 
Methoden zusätzlichen Aufwand zur Laufzeit. Vorschläge zur Reduktion die- 
ses Aufwandes existieren‘. Dennoch können der verbleibende Aufwand und 
die potentiell schlechte Vorhersage des Zeitverhaltens für performanzkritische 
Systeme möglicherweise nicht tragbar sein. 

— Aspektorientierte Programmierung [351]: dieser Ansatz erlaubt es, Aspek- 
te von Software, die orthogonal zueinander sind, unabhängig voneinander zu 
beschreiben und automatisch in alle relevanten Teile des Programmcodes ein- 
zubauen. So könnte Profiling-Code in einem eigenen Modul beschrieben sein, 
das dann automatisch zu allen relevanten Teilen des Quellcodes hinzugefügt 
oder aus diesen entfernt werden kann. Die CiAO-Betriebssystemfamilie wurde 
auf diese Weise entworfen [352]. 

— Bedingte Übersetzung: Hier kommt ein Makro-Präprozessor zum Einsatz, 
dessen Befehle #if und #ifdef verwendet werden. 

— Erweiterte Auswertung zur Ubersetzungszeit (engl. compile time evaluati- 
on): ein Betriebssystem könnte konfiguriert werden, indem bestimmte Varia- 
blen vor der Übersetzung mit konstanten Werten belegt werden. Ein Compiler 
könnte dann das Wissen über diese Werte so weit wie möglich ausnutzen. Hier 
könnten auch erweiterte Compiler-Optimierungen nützlich sein. Wenn ein 
bestimmter Funktionsparameter beispielsweise stets einen konstanten Wert 
besitzt, könnte dieser Parameter aus der entsprechenden Parameterliste ent- 
fernt werden. Die sogenannte partielle Evaluation [277] stellt eine Umgebung 
für solche Compileroptimierungen zur Verfügung. Weiterführende Ansätze 
könnten zudem dynamische Daten durch statische Daten ersetzen [25]. Ein 


? Studierende, die bisher keine Vorlesung über Betriebssysteme gehört haben, sollten eines dieser 
Standardwerke zu Rate ziehen, bevor sie hier weiterlesen. 


3 Diese Liste ist nach der Position der Technik im Entwicklungsprozess geordnet. 


4 https://github.com/lefticus/cppbestpractices/blob/master/08-Considering_Performance.md ist ein 
Beispiel dafiir. 
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Überblick über Ansätze der Betriebssystemspezialisierung wurde von McNa- 
mee et al. veröffentlicht [388]. 

— Linker-basierte Entfernung ungenutzter Funktionen: Oft stehen zur Link- 
Zeit mehr Informationen darüber zur Verfügung, welche Funktionen verwendet 
und welche nicht verwendet werden. So kann ein Linker z.B. herausfinden, 
welche Funktionen einer Bibliothek tatsächlich benutzt werden. Entsprechend 
können nicht verwendete Bibliotheksfunktionen entfernt werden und weitere 
Spezialisierungen stattfinden [91]. 


Diese Techniken werden meist mit einer regelbasierten Auswahl der für das 
jeweilige Betriebssystem benötigten Dateien kombiniert. Die Maßschneiderung 
des Betriebssystems kann durch eine graphische Benutzerschnittstelle vereinfacht 
werden, welche die eigentlichen Konfigurationstechniken vor dem Entwickler 
verbirgt. Das VxWorks-Betriebssystem der Firma Wind River [590] wird bei- 
spielsweise über eine solche graphische Benutzerschnittstelle konfiguriert. 

Eines der möglichen Probleme bei Systemen mit einer großen Anzahl abge- 
leiteter, maßgeschneiderter Betriebssysteme ist die Verifikation. Jedes einzelne 
abgeleitete Betriebssystem muss sorgfältig getestet werden. Takada erwähnt dies 
als ein mögliches Problem für eCos (ein Open Source-Echtzeitbetriebssystem der 
Firma Red Hat [382]), das über 100 bis 200 Konfigurationsmöglichkeiten verfügt 
[523]. Auch bei Linux ist das ein Problem [526]. Die Verwendung von Techniken 
der Software-Produktlinienentwicklung [456] kann Ansätze liefern, um dieses 
Problem zu lösen. 

e Eingebettete Systeme nutzen eine große Vielfalt an Peripheriegeräten. Viele ein- 
gebettete Systeme besitzen weder Festplatte, Tastatur, Bildschirm oder Maus. Es 
gibt kein Gerät, das von allen Varianten eines Betriebssystems unterstützt 
werden muss, vielleicht mit Ausnahme des Systemzeitgebers. Anwendungen sind 
oft dazu entworfen, bestimmte Geräte zu nutzen. In solchen Fällen müssen Geräte 
nicht von verschiedenen Anwendungen gleichzeitig benutzt werden. Damit ist es 
auch nicht erforderlich, dass das Betriebssystem diese Geräte verwaltet. Durch 
die große Anzahl an Geräten wäre es auch schwierig, alle benötigten Gerätetrei- 
ber zusammen mit dem Betriebssystem zur Verfügung zu stellen. Daher ist es 
sinnvoll, Betriebssystem und Geräte durch die Verwendung spezieller Prozesse 
zu entkoppeln, anstatt die Gerätetreiber in das Betriebssystem zu integrieren. 
Durch die begrenzte Geschwindigkeit vieler eingebetteter Systeme ist es auch 
nicht notwendig, die Treiber aus Performanzgründen in das Betriebssystem zu 
integrieren. Dies kann zu einer geänderten Anordnung der einzelnen Softwa- 
reschichten eines Systems führen. Bei PCs wird davon ausgegangen, dass be- 
stimmte Treiber, wie solche für Festplatten, Netzwerkkarten, oder Audioausgabe, 
stets verfügbar sind. Diese sind auf einer weit unten liegenden Schicht imple- 
mentiert. Anwendungssoftware und Middleware sind oberhalb der Anwendungs- 
Programmierschnittstelle implementiert, wie es für alle Anwendungen üblich ist. 
Bei einem eingebetteten Betriebssystem hingegen werden Gerätetreiber häufig 
oberhalb des Kernels implementiert. Anwendungen und Middleware wiederum 
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können dann oberhalb der zugehörigen Treiber implementiert werden, d.h. nicht 
basierend auf einer standardisierten API (siehe Abb. 4.2). 


Anwendungssoftware Anwendungssoftware 
Middleware | Middleware Middleware | Middleware 
Gerätetreiber | Gerätetreiber Betriebssystem-Kern 

Betriebssystem-Kern Gerätetreiber | Gerätetreiber 


Abb. 4.2 Gerätetreiber: (links:) oberhalb und (rechts:) unterhalb des Betriebssystem-Kerns 


e Schutzmechanismen sind nicht immer erforderlich, da eingebettete Systeme 
oft für einen bestimmten Zweck entworfen werden (es wird nicht angenommen, 
dass sie sogenanntes ,,Multiprogramming” unterstützen). Daher kommt es selten 
vor, dass ungetestete Programme geladen werden. Nach dem Testen von Software 
könnte davon ausgegangen werden, dass diese zuverlässig ist. Dies trifft genauso 
auf die Eingabe und Ausgabe zu. Im Gegensatz zu Desktop-Anwendungen müssen 
Ein/Ausgabeoperationen nicht als privilegierte Befehle implementiert werden, 
Prozesse dürfen eigenständig Eingaben und Ausgaben vornehmen. Dies passt gut 
zum vorher angesprochenen Punkt und senkt den Aufwand für E/A-Vorgänge. 


Beispiel 4.1: Sei switch die (in den Speicheradressbereich abgebildete) E/A- 
Adresse eines Schalters, der von einem Programm abgefragt werden soll. Dies 
kann einfach mit dem Befehl 


load register, switch 


erfolgen. Es ist nicht notwendig, dafür einen Betriebssystemdienst aufzurufen, 
der einen erheblichen Aufwand zum Sichern und Wiederherstellen des Prozess- 
kontextes (Register usw.) erfordern würde. V 


Es ist aber ein Trend hin zu dynamischeren eingebetteten Systemen feststell- 
bar. Zudem können Sicherheitsanforderungen Schutzvorrichtungen notwendig 
machen. Zu diesem Zweck wurden spezielle Speicherschutzeinheiten (engl. Me- 
mory Protection Units (MPUs)) entworfen, ein Beispiel dafür findet sich in [164]. 
Für Systeme mit einer Mischung von kritischen und unkritischen Anwendungen 
(engl. mixed-criticality systems) kann ein konfigurierbarer Speicherschutz [353] 
ein Ziel sein. 

e Unterbrechungen (engl. interrupts) können mit beliebigen Prozessen verbun- 
den werden. Über Betriebssystemdienste können wir anfordern, dass bestimmte 
Prozesse gestartet oder beendet werden, wenn eine bestimmte Unterbrechung auf- 
tritt. Wir könnten sogar die Startadresse eines Prozesses direkt in der Interrupt- 
Vektortabelle hinterlegen. Diese Methode ist allerdings sehr gefährlich, da das 
Betriebssystem dann nicht darüber informiert wäre, dass dieser Prozess tatsäch- 
lich läuft. Darunter könnte auch die Kompatibilität leiden: wenn ein bestimmter 
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Prozess direkt mit einer Unterbrechung verbunden ist, Könnte es schwierig sein, 
einen weiteren Prozess hinzuzufügen, der ebenfalls von einem bestimmten Ereig- 
nis gestartet werden soll. Wenn anwendungsspezifische Gerätetreiber verwendet 
werden, könnten diese ebenfalls Verbindungen zwischen Unterbrechungen und 
Prozessen herstellen. Techniken zur Herstellung sicherer Verbindungen wurden 
von Hofer et al. untersucht [219]. 

e Viele eingebettete Betriebssysteme sind Echtzeitsysteme. Daher muss das ver- 
wendete Betriebssystem ein echtzeitfähiges Betriebssystem (engl. Real-Time 
Operating System (RTOS)) sein. 


Weiterführende Informationen über eingebettete Betriebssysteme finden sich in 
einem von Bertolotti geschriebenen Buchkapitel [51]. Dieses Kapitel beinhaltet 
Informationen über die Architektur eingebetteter Betriebssysteme, den POSIX- 
Standard, Open Source-Echtzeitbetriebssysteme und Virtualisierung. 


4.1.2 Echtzeitbetriebssysteme 


Definition 4.3: Nach Takada [523] ist „Ein Echtzeitbetriebssystem ... ein Betriebs- 
system, das die Erstellung von Echtzeitsystemen unterstützt”. 


Es gibt vier Eigenschaften, welche die Echtzeitfähigkeit eines Betriebssystems aus- 
machen>: 


e Das Zeitverhalten des Betriebssystems muss vorhersagbar sein. Für jeden 

Dienst des Betriebssystems muss eine obere Schranke fiir die entsprechende 
Ausfiihrungszeit garantiert sein. In der Praxis unterscheidet man zwischen ver- 
schiedenen Stufen der Vorhersagbarkeit. So kann es Mengen von Systemaufrufen 
geben, für die eine obere Schranke bekannt ist und deren Ausführungszeit nicht 
signifikant schwankt. Ein solcher Aufruf könnte „liefere die aktuelle Tageszeit” 
sein. Bei anderen Aufrufen könnte es dagegen starke Schwankungen geben. Auf- 
rufe wie „reserviere 4 MB freien Speicher” könnten in diese zweite Klasse fallen. 
Insbesondere muss das Scheduling-Verfahren jedes RTOS deterministisch sein. 
Unter bestimmten Umständen kann es notwendig sein, Unterbrechungen zu sper- 
ren, um die gegenseitige Beeinflussung zwischen bestimmten Teilen des Be- 
triebssystems zu vermeiden. Unterbrechungen können auch gesperrt werden, um 
Wechselwirkungen zwischen Prozessen zu vermeiden; dies ist jedoch meist von 
geringerer Bedeutung. Die Zeiträume, in denen Unterbrechungen gesperrt sind, 
sollten sehr kurz sein, um nicht vorhersagbare Verzögerungen bei der Abarbeitung 
kritischer Ereignisse zu vermeiden. 
Wenn ein RTOS ein Dateisystem auf einer Festplatte implementiert, kann es 
notwendig sein, grundsätzlich unfragmentierte Dateien (Dateien, deren Blöcke in 
aufeinanderfolgenden Festplattenbereichen gespeichert sind) zu implementieren, 
um unvorhersagbare Bewegungen der Festplattenköpfe zu vermeiden. 


5 Dieser Abschnitt beinhaltet Informationen aus dem Tutorial von Hiroaki Takada [523]. 
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e Das Betriebssystem muss das Scheduling der Prozesse durchführen. Sche- 
duling kann definiert werden als die Zuordnung von Mengen von Prozessen auf 
Intervalle der Ausfiihrungszeit, mit dem Spezialfall der Abbildung auf bestimmte 
Startzeiten. Möglicherweise muss das Betriebssystem auch Deadlines bestimm- 
ter Prozesse kennen. Es gibt aber auch Fälle, in denen das Scheduling komplett 
zur Entwurfszeit stattfindet, dann muss das Betriebssystem nur Dienste bereit- 
stellen, um Prozesse zu bestimmten Zeiten und auf bestimmten Prioritätsebenen 
zu starten. Scheduling-Algorithmen werden detailliert in Kapitel 6 behandelt. 

« Einige Dienste erfordern, dass das Betriebssystem Zeit verwaltet. Eine solche 
Verwaltung ist unerlässlich, wenn die interne Abarbeitung mit einer absoluten Zeit 
in der physikalischen Umgebung in Verbindung steht. Physikalische Zeit wird 
durch reelle Zahlen beschrieben, Computer dagegen verwenden meist diskrete 
Zeitangaben. Die jeweiligen genauen Anforderungen können dabei variieren: 


1. Einige Systeme erfordern die Synchronisation mit globalen Zeitstandards. 
Diese führen eine globale Uhrensynchronisation durch. Dafür existieren 
zwei unterschiedliche Standards: 

— Die Universal Time Coordinated (UTC): Die UTC wird durch astronomi- 
sche Standards definiert. Dieser Standard muss von Zeit zu Zeit aufgrund 
von Abweichungen der Erdbewegung angepasst werden. Beim Übergang 
von einem Jahr auf das folgende werden dabei einige Sekunden hinzugefügt. 
Diese Anpassungen können zu Problemen führen, da fehlerhaft implemen- 
tierte Software davon ausgehen könnte, dass das folgende Jahr in derselben 
Nacht zweimal beginnt. 

— Die Internationale Atomzeit (französisch temps atomic internationale 
(TAD). Dieser Standard unterliegt nicht den oben beschriebenen Beschrän- 
kungen. 

Die genaue Zeitinformation wird über eine Verbindung mit der Umgebung er- 

mittelt. Externe Synchronisierung basiert dabei meist auf Funkübertragungs- 

standards, wie z.B. dem Globalen Positionierungs-System (GPS) [414], Mobil- 
funknetzwerken oder speziellen Langwellensendern zur Steuerung von Funk- 
uhren [579]. Die Sender verbreiten eine Zeit auf der Basis von Atomuhren, in 

Mitteleuropa mittels des DCF77-Systems. 

2. Wenn eingebettete Systeme in einem Netzwerk eingesetzt werden, reicht es oft 
aus, Zeitinformation innerhalb des Netzwerks zu synchronisieren. Hierfür kann 
lokale Uhrensynchronisation zum Einsatz kommen. Damit können miteinander 
verbundene eingebettete Systeme versuchen, eine einheitliche Zeitbasis zu 
bestimmen. 

3. Es kann zudem Fälle geben, in denen es lediglich notwendig ist, präzise lokale 
Verzögerungen zu realisieren. 


Einige Anwendungen benötigen präzise Zeitdienste mit einer hohen Auflösung. 
Dies ist beispielsweise erforderlich, um zwischen ursprünglichen Fehlern und Fol- 
gefehlern in einem System unterschieden zu können. Diese können beispielsweise 
dazu genutzt werden, um Kraftwerke zu identifizieren, die für einen Stromausfall 
verantwortlich sind (siehe [428]). Die Genauigkeit von Zeitdiensten hängt davon 
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ab, wie diese auf einer bestimmten Ausführungsplattform unterstützt werden. 
Wenn die Implementierung durch Prozesse auf Anwendungsebene erfolgt, sind 
sie sehr unpräzise (mit einer Genauigkeit im Millisekunden-Bereich). Zeitdienste 
sind sehr präzise (mit Genauigkeiten im Mikrosekunden-Bereich), wenn sie von 
der Kommunikationshardware unterstützt werden. Weitere Informationen über 
Zeitdienste und Uhrensynchronisation finden sich im Buch von Kopetz [304]. 

« Das Betriebssystem muss schnell sein. Ein Betriebssystem, das alle bisher ange- 
führten Anforderungen erfüllt, wäre nutzlos, wenn es selbst langsam wäre. Daher 
muss ein Betriebssystem offensichtlich schnell sein. 


Jedes RTOS beinhaltet einen sogenannten Echtzeitkern. Dieser verwaltet die 
Ressourcen, die in jedem Echtzeitsystem vorhanden sind, wie z.B. den Prozessor, 
den Speicher und die Systemzeitgeber. Wichtige Funktionen des Echtzeitkerns sind 
die Verwaltung von Prozessen, Synchronisation und Kommunikation zwischen Pro- 
zessen, Zeitverwaltung und Speicherverwaltung. 

Einige RTOS wurden für allgemeine eingebettete Anwendungen entworfen, wäh- 
rend andere sich auf bestimmte Anwendungsgebiete spezialisiert haben. So sind 
beispielsweise OSEK/VDX® -kompatible Betriebssysteme speziell für den Einsatz 
in Steuergeräten im Automobilbereich gedacht. Betriebssysteme für einen bestimm- 
ten Anwendungsbereich stellen bestimmte Dienste für diesen speziellen Bereich zur 
Verfügung; sie können dadurch kompakter sein als Betriebssysteme, die für mehrere 
Anwendungsbereiche geeignet sind. 

In ähnlicher Weise gibt es RTOS, die eine Standard-Programmierschnittstelle 
anbieten, während andere Systeme eine eigene, proprietäre API besitzen. So im- 
plementieren einige RTOS die standardisierte POSIX RT-Erweiterung für UNIX 
[202], andere implementieren den OSEK ISO 17356-3:2005-Standard oder die in 
Japan entwickelte ITRON-Spezifikation®. Viele Echtzeitbetriebssysteme verwenden 
ihre eigene API. Das erwähnte ITRON ist ein industrieerprobtes RTOS, das die 
Konfiguration zur Link-Zeit ermöglicht. 

Die verfügbaren RTOS lassen sich weiterhin nach den folgenden Kriterien unter- 
scheiden [194]: 


e Schnelle, proprietäre Kerne: Nach Gupta sind „diese Kerne nicht für komplexe 
Systeme geeignet, da sie entworfen wurden, um schnell zu sein, aber nicht, um 
in jeder Hinsicht vorhersagbar zu sein”. Beispiele für solche Systeme sind QNX, 
PDOS, VCOS, VTRX32 und VxWorks. 

« Um Echtzeitfunktionen erweiterte Standard-Betriebssysteme: Hybride Sys- 
teme wurden entwickelt, um die Vorteile komfortabler Standard-Betriebssysteme 
nutzen zu können. In solchen Systemen gibt es einen besonderen Echtzeit- 
kern, der alle Echtzeitprozesse verwaltet. Das Standard-Betriebssystem wird 
dann als ein solcher Prozess ausgeführt (siehe Abb. 4.3). Dieser Ansatz bietet 
einige Vorteile: das System verfügt über eine standardisierte Betriebssystem- 
Programmierschnittstelle (API) und kann eine graphische Benutzerschnittstel- 
le (GUI) sowie Dateisysteme usw. realisieren. Zudem sind Erweiterungen des 


6 Siehe http://www.ertl.jp/ITRON/ . 
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Echtzeit- | Echtzeit- Nicht-Echtzeit- | Nicht-Echtzeit- 
Prozess 1 | Prozess 2 Prozess 1 Prozess 2 
Gerätetreiber|Gerätetreiber Standard-OS 


Abb. 4.3 Hybride Betriebssysteme 


Standard-Betriebssystems schnell auch in eingebetteten Systemen verfügbar. 
Probleme, die das Standard-Betriebssystem und dessen nicht-Echtzeit-Prozesse 
betreffen, beeinflussen die Echtzeitprozesse nicht. Dies geht so weit, dass das 
Standard-Betriebssystem sogar abstürzen kann und die Echtzeitprozesse davon 
unbeeinflusst weiterlaufen. Ein Problem mit diesem Ansatz ist ebenfalls in Abb. 
4.3 zu sehen: Gerätetreiber könnten Probleme verursachen, da das Standard- 
Betriebssystem über eigene Treiber verfügt. Um Wechselwirkungen zwischen 
Treibern für Echtzeitprozesse und denen für andere Prozesse zu vermeiden, kann 
es notwendig sein, die Menge der Geräte in solche, die durch Echtzeitprozesse 
behandelt werden und solche, die durch das Standard-Betriebssystem behan- 
delt werden, zu unterteilen. Echtzeitprozesse können zudem keine Dienste des 
Standard-Betriebssystems nutzen. Damit sind alle nützlichen Eigenschaften wie 
ein Dateisystemzugriff und graphische Benutzerschnittstellen für diese Prozesse 
normalerweise nicht verfügbar. Es existieren aber erste Ansätze, die Unterschie- 
de zwischen den beiden Arten von Prozessen zu überbrücken, ohne die Echt- 
zeitfähigkeiten zu verlieren. RT-Linux ist ein Beispiel für ein solches hybrides 
Betriebssystem. 
Nach Gupta [194] ist die Verwendung eines Standard-Betriebssystems „nicht der 
richtige Ansatz, da zu viele grundlegende und unpassende Voraussetzungen exis- 
tieren wie die Optimierung für den durchschnittlichen Fall (anstelle des worst 
case), ... das Ignorieren der meisten oder der gesamten semantischen Informatio- 
nen und unabhängiges Scheduling der CPU sowie Allokation von Ressourcen.” 
Abhängigkeiten zwischen Prozessen kommen bei den meisten Anwendungen auf 
Standard-Betriebssystemen tatsächlich sehr selten vor und werden von solchen 
Systemen daher häufig ignoriert. Bei eingebetteten Systemen ist die Lage anders, 
da Abhängigkeiten zwischen Prozessen die Regel sind und daher berücksichtigt 
werden müssen. Dies ist jedoch nicht immer der Fall, wenn Erweiterungen von 
Standard-Betriebssystemen zum Einsatz kommen. Zudem betrachten Standard- 
Betriebssysteme Ressourcenzuteilung und Scheduling selten in Kombination. In- 
tegrierte Ressourcenzuteilung und Scheduling-Algorithmen sind aber notwendig, 
um das Einhalten von Zeitbedingungen garantieren zu können. 

e Einige Forschungssysteme versuchen, die oben beschriebenen Einschränkungen 
zu vermeiden. Dazu zählen Melody [568] sowie (nach Gupta [194]) MARS, 
Spring, MARUTI, Arts, Hartos und DARK. 


Takada [523] nennt leichtgewichtigen Speicherschutz, zeitlichen Schutz von Re- 
chenressourcen (um Prozesse davon abzuhalten, länger zu rechnen als ursprünglich 
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geplant), RTOS fiir Multiprozessor-Systeme auf einem Chip (speziell fiir heteroge- 
ne Multiprozessoren und mehrfadige (engl. multi-threaded) Prozessoren) sowie die 
Unterstützung für Medienströme und Dienstgüte als Forschungsfragen. 

Das erwartete Wachstum des Marktes für das Internet der Dinge führt dazu, 
dass die Hersteller von Standard-Betriebssystemen versuchen, angepasste Versionen 
ihrer Produkte zu vermarkten und damit spezialisierten Anbietern wie Wind River 
Systems [591] Marktanteile abzuringen. Aufgrund zunehmender Netzanbindung von 
eingebetteten Systemen werden Linux und davon abgeleitete Systeme populär. Vor- 
und Nachteile des Einsatzes von Linux in solchen Systemen werden im Abschnitt 
4.4 beschrieben. 


4.1.3 Virtuelle Maschinen 


In bestimmten Umgebungen kann es von Vorteil sein, mehrere Prozessoren auf 
einem einzelnen echten Prozessor zu emulieren. Dies wird durch virtuelle Maschi- 
nen, die direkt auf der Hardware ausgeführt werden, ermöglicht. Auf Basis einer 
solchen virtuellen Maschine können dann verschiedene Betriebssysteme realisiert 
werden. Damit können mehrere Betriebssysteme auf einem einzigen Prozessor im- 
plementiert werden. Bei eingebetteten Systemen muss dieser Ansatz mit Vorsicht 
betrachtet werden, da das Zeitverhalten hier problematischer sein kann und die zeit- 
liche Vorhersagbarkeit verloren gehen könnte. Dennoch kann es Fälle geben, in 
denen dieser Ansatz nützlich ist. Beispielsweise könnte es die Anforderung geben, 
mehrere existierende Anwendungen, die verschiedene Betriebssysteme nutzen, auf 
einem einzelnen Prozessor zu integrieren. Eine vollständige Betrachtung virtueller 
Maschinen würde den Rahmen dieses Buches sprengen. Der interessierte Leser sei 
daher auf die Bücher von Smith et al. [502] und Craig [114] verwiesen. PikeOS ist 
ein Beispiel für ein Virtualisierungskonzept, das speziell für eingebettete Systeme 
entwickelt wurde [520]. PikeOS ermöglicht es, die Ressourcen eines Systems (z.B. 
Speicher, E/A-Geräte, CPU-Zeit) in einzelne Teilmengen aufzuteilen. PikeOS stellt 
einen kleinen Mikrokern zur Verfügung. Auf Basis dieses Kerns können verschie- 
dene Betriebssysteme, Programmierschnittstellen (APIs) und Laufzeitumgebungen 
(engl. Run-Time Environments (RTEs)) implementiert werden (siehe Abb. 4.4). 


Anwendung 1 | | Anwendung 2 | | Anwendung 3 
OS 1 API 1 RTE 1 
PikeOS 
Hardware 


Abb. 4.4 PikeOS-Virtualisierung (OSYSGO) 
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4.2 Protokolle fiir Ressourcen-Zugriffe 


In diesem Unterabschnitt benutzen wir den Begriff des Jobs. 


Definition 4.4: Ein Job ist eine konkrete Ausführung einer (möglicherweise wie- 
derholt auszuführenden) Task. 


Ein Job ist eine abstraktere Sicht auf auszuführende Berechnungen als Prozesse 
und Threads in Betriebssystemen, auf die Jobs letztlich im Rahmen des Entwurfs 
abgebildet werden müssen. Eine Präzisierung dieser Definition wird in Definition 
6.1 gegeben. 


4.2.1 Prioritätsumkehr 


In einigen Fällen muss sichergestellt werden, dass Jobs exklusiven Zugriff auf Res- 
sourcen wie gemeinsame globale Variablen oder Geräte erhalten, um nichtdeter- 
ministisches oder anderweitig unerwünschtes Programmverhalten zu vermeiden. 
Dieser exklusive Zugriff ist besonders wichtig bei eingebetteten Systemen, z.B. zur 
Implementierung von Kommunikation über gemeinsamen Speicher oder für den ex- 
klusiven Zugriff auf ein bestimmtes Hardwaregerät. Die Programmabschnitte, die 
einen solchen exklusiven Zugriff während ihrer Ausführung benötigen, werden kri- 
tische Abschnitte genannt. Kritische Abschnitte sollten kurz ein. Betriebssysteme 
stellen meist Grundfunktionen (engl. primitives) zur Verfügung, um exklusiven Zu- 
griff auf Ressourcen anzufordern und wieder freizugeben, diese werden auch Mutexe 
(für „mutual exclusion” = gegenseitiger Ausschluss) genannt. Jobs, die keinen exklu- 
siven Zugriff erhalten, müssen warten, bis die entsprechende Ressource freigegeben 
wird. Demzufolge muss die Freigabeoperation prüfen, ob es wartende Jobs gibt und 
den Job mit höchster Priorität fortsetzen. 

In diesem Buch nennen wir die Anforderungsoperation P(S) und die Freigabeope- 
ration V(S), wobei S für die jeweilige Ressource steht. P(S) und V(S) sind sogenannte 
Semaphor-Operationen. Semaphore ermöglichen es, dass bis zu n (wobei n ein 
Parameter ist) Jobs eine bestimmte Ressource, die von S geschützt wird, gleichzeitig 
benutzen können. S kennzeichnet dabei eine Datenstruktur, die einen Zähler ent- 
hält, der angibt, wie viele Ressourcen noch verfügbar sind. P(S) prüft diesen Zähler 
und blockiert den Aufrufer, wenn alle Ressourcen bereits belegt sind. Anderenfalls 
wird der Zähler verändert und der Aufrufer darf fortfahren. V(S) inkrementiert die 
Anzahl verfügbarer Ressourcen und stellt sicher, dass ein blockierter Aufrufer (falls 
einer existiert) fortfahren kann. Wichtig ist, dass die Operationen P(S) und V(S) un- 
teilbar sind, d.h. nie durch andere Operationen unterbrochen werden können. Die 
Bezeichnungen P(S) und V(S) entstammen der niederländischen Sprache. Wir ver- 
wenden diese Operationen nur in Form von binären Semaphoren mit n = 1, d.h., wir 
erlauben nur einem einzigen Aufrufer, die Ressource zu nutzen. 

In eingebetteten Systemen sind Abhängigkeiten zwischen Jobs die Regel und kei- 
ne Ausnahme. Auch ist die effektive Jobpriorität von Echtzeitanwendungen wichtiger 
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als bei nicht-Echtzeit-Anwendungen. Gegenseitiger Ausschluss kann zur Prioritäts- 
umkehr führen, welche die effektive Priorität von Jobs ändert. Auch bei nicht einge- 
betteten Systemen kommt Prioritätsumkehr vor. Aus den vorher genannten Gründen 
ist das Problem der Prioritätsumkehr aber bei eingebetteten Systemen schwerwie- 
gender. 

Ein erstes Beispiel für die Folgen, die aus einer Kombination von gegenseitigem 
Ausschluss und Nichtentzug von Prozessorressourcen entstehen, ist in Abb. 4.5 
dargestellt. In diesem Unterabschnitt nutzen wir Material aus dem Buch von Buttazzo 
[81]. 
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Normale Ausführung kritischer Abschnitt 


Abb. 4.5 Blockieren eines Jobs durch einen Job niedrigerer Priorität 


Fettgedruckte, nach oben zeigende Pfeile kennzeichnen die Zeitpunkte, zu denen 
Jobs ausführbar oder „bereit” werden. Zum Zeitpunkt to betritt Job Jz einen kri- 
tischen Abschnitt, nachdem er exklusiven Zugriff auf eine Ressource mittels einer 
P-Operation angefordert und erhalten hat. Zum Zeitpunkt tı wird Job J; ausführbe- 
reit und verdrängt J2. Zum Zeitpunkt t2 erhält J; keinen exklusiven Zugriff auf die 
gerade von Ja belegte Ressource und wird blockiert. Job J2 Kann fortfahren und gibt 
die Ressource einige Zeit später wieder frei. Die Freigabeoperation prüft, ob Jobs 
höherer Priorität warten und verdrängt J2. Während der Zeit, in der J; blockiert war, 
hat also ein Job niederer Priorität einen Job mit höherer Priorität effektiv blockiert. 
Die Notwendigkeit, exklusiven Zugriff auf einige Ressourcen zur Verfügung zu stel- 
len, ist die Hauptursache für diesen Effekt. Im Fall von Abb. 4.5 kann die Dauer 
der Blockierung die Länge des kritischen Abschnitts von J glücklicherweise nicht 
überschreiten. Diese Situation ist problematisch, aber nur schwierig zu vermeiden. 

Im allgemeinen Fall kann die Situation noch deutlich schlimmer sein. Dies ist 
z.B. in Abb. 4.6 dargestellt. Gegeben seien die Jobs Jj, J2 und J3. Jı besitzt die 
höchste Priorität, J2 eine mittlere und J3 die niedrigste Priorität. Wir nehmen an, 
dass J; und J3 exklusiven Zugriff auf eine Ressource mittels der Operation P(S) 
anfordern. Sei J3 nun in seinem kritischen Abschnitt, wenn er von J verdrängt wird. 
Wenn J; nun J verdrängt und versucht, auf dieselbe Ressource zuzugreifen, auf die 
J3 gerade exklusiven Zugriff hat, blockiert dieser und J» kann fortfahren. Solange 
J fortfährt, kann J3 die Ressource nicht freigeben. Daher blockiert Jz effektiv Jı, 
obwohl die Priorität von J; höher als die von J ist. In diesem Beispiel wird Jı bis 
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P(S) [blockiert] fortfahren 


jan 


blockieren 
P(S) | : : V(S) t 


normale Ausführung kritischer Abschnitt 


Abb. 4.6 Prioritätsumkehr mit möglicher großer Verzögerung 


zum Ende der Laufzeit von J2 blockiert. Jı wird von einem Job niederer Priorität 
blockiert, der sich nicht in seinem kritischen Abschnitt befindet. Dieser Effekt wird 
Prioritätsumkehr” genannt. Tatsächlich findet die Prioritätsumkehr statt, obwohl 
Jz nicht direkt mit Jı und J3 in Verbindung steht. Die Dauer der Prioritätsumkehr 
ist nicht durch die Länge irgendeines kritischen Abschnitts beschränkt. Dieses und 
weitere Beispiele können mit Hilfe der levi-Simulationssoftware simuliert werden 
[497]. 

Einer der bekanntesten Fälle von Prioritätsumkehr betraf den Mars Pathfinder, 
in dem ein exklusiver Zugriff auf einen gemeinsam benutzten Speicherbereich zur 
Prioritätsumkehr auf dem Mars führte [276]. 


4.2.2 Prioritätsvererbung 


Ein Ansatz zum Umgang mit Prioritätsumkehr ist die Verwendung des Prioritätsver- 
erbungs-Protokolls (engl. Priority Inheritance Protocol (PIP)). Dieses Protokoll ist 
in vielen Echtzeitbetriebssystemen verfügbar. Es funktioniert wie folgt: 


e Jobs werden entsprechend ihrer aktiven Prioritäten zugeteilt. Jobs mit derselben 
Priorität werden auf first-come, first-served-Basis zugeteilt. 

e Wenn ein Job Jı die Operation P(S) ausführt und ein anderer Job Jọ bereits ex- 
klusiven Zugriff darauf hat, wird J; blockiert. Wenn die Priorität von Jz niedriger 
als die von J; ist, erbt Jz die Priorität von Jı. Damit kann Jp die Ausführung 
fortsetzen. Allgemein betrachtet, erbt jeder Job die höchste Priorität aller Jobs, 
die durch ihn blockiert werden. 

e Wenn ein Job Jz die Operation V(S) ausführt, wird seine Priorität auf die höchste 
Priorität aller Jobs, die von ihm blockiert werden, reduziert. Wenn kein weiterer 
Job von Jz blockiert wird, wird dessen Priorität auf den ursprünglichen Wert 
zurückgesetzt. Zudem wird der Job mit der höchsten Priorität, der bisher beim 
Zugriff auf S blockiert wurde, fortgesetzt. 


7 Einige Autoren sehen bereits den in Abb. 4.5 gezeigten Fall als Prioritätsumkehr an. Dies war 
auch in früheren Ausgaben dieses Buchs der Fall. 
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e Prioritätsvererbung ist transitiv: wenn J, Job Jy blockiert und J, Job J, blockiert, 
dann erbt J, die Priorität von Jz. 


Wenn Jobs einer hohen Priorität durch Jobs mit einer niedrigen Priorität blockiert 
werden, dann geben sie ihre Priorität an die Jobs der niedrigen Priorität weiter, 
sodass diese ihre Semaphore so schnell wie möglich freigeben können. Im Beispiel 
von Abb. 4.6 würde J3 die Priorität von J; erben, sobald J; P(S) ausführt. Dies würde 
das genannte Problem vermeiden, da J2 nun J3 nicht verdrängen würde (siehe Abb. 
4.7). 


P(S) [blockiert] fortfahren 


= = — 
P(S) : : V(S) t 
normale Ausführung kritischer Abschnitt 


Abb. 4.7 Prioritätsvererbung fiir das Beispiel von Abb. 4.6 


Abb. 4.8 zeigt ein Beispiel fiir verschachtelte kritische Abschnitte [81]. Beachten 
Sie, dass die Priorität von Job J3 zum Zeitpunkt fo nicht auf ihren ursprünglichen 
Wert zurückgesetzt wird. Stattdessen wird seine Priorität auf den niedrigsten Wert 
der von ihm blockierten Jobs gesetzt, in diesem Fall die Priorität pı von Jı. 


P(a) V(a) 
Jy a 
P(b) | V(b) 

J b 

P(a) P(b) V(b) V(a) 
J fi a |b b bla 

3 A Priorität | | Ir Priorität ändert sich nicht 
Pı | von T 
P2 
P3 
to t 


Abb. 4.8 Verschachtelte kritische Abschnitte 


Die Transitivität der Prioritätsvererbung ist in Abb. 4.9 dargestellt [81]. Zum 
Zeitpunkt tọ wird Jı von Jz blockiert, der wiederum von J3 blockiert wird. Daher 
erbt J3 die Priorität pı von Jı. 
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Abb. 4.9 Transitivität der Prioritätsvererbung 


Prioritätsvererbung wird auch von Ada verwendet: während eines Rendez-Vous 
wird die Priorität der betroffenen Codeobjekte auf deren Maximum gesetzt. 

Prioritätsvererbung löste auch das Problem des Mars Pathfinder: das verwendete 
VxWorks-Betriebssystem besitzt einen Booleschen Parameter für Aufrufe von Mutex- 
Grundfunktionen. Dieser Parameter erlaubt es, die Prioritätsvererbung zu nutzen. Im 
Auslieferungszustand der Software war Prioritätsvererbung deaktiviert. Das Problem 
auf dem Mars wurde beseitigt, indem dieser Parameter mittels der Debugging- 
Funktionalität von VxWorks modifiziert und die Prioritätsvererbung damit aktiviert 
wurde, als der Pathfinder sich bereits auf dem Mars befand [276]. Prioritätsvererbung 
kann mit Hilfe der levi-Simulationssoftware simuliert werden [497]. 

Prioritätsvererbung kann einige Problem lösen, aber bei Weitem nicht alle. So 
könnte es eine große Anzahl von Jobs mit hoher Priorität geben. Auch kann es 
Deadlocks geben, was anhand eines Beispiels gezeigt werden kann [31]. 


Beispiel 4.2: Angenommen, es gäbe zwei Jobs Jı und J2. Für Job J; nehmen wir 
eine Codesequenz der Form ...; P(a); P(b); V(b); V(a); ...; an. Für Job Jo nehmen 
wir eine Codesequenz der Form ...; P(b); P(a); V(a); V(b); ...; an. Eine mögliche 
Ausführungsreihenfolge ist in Abb. 4.10 zu sehen. Wir nehmen an, dass die Priorität 
von J; höher ist als die von J2. Daher verdrängt J; den Job Jo zum Zeitpunkt tı 


Abb. 4.10 Prioritätsvererbung mit Deadlock 
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und wird ausgeführt bis er P(b) ruft, während b durch J2 gehalten wird. Daher wird 
J2 wieder ausgeführt. Job J wird blockiert, wenn er P(a) aufruft. Dieser Deadlock 
würde auch ohne Nutzung eines Protokolls zum Ressourcenzugriff existieren. V 


4.2.3 Priority Ceiling-Protokoll 


Deadlocks können mit dem Priority Ceiling-Protokoll (PCP) [485] vermieden wer- 
den, bei dem die Jobs zur Entwurfszeit bekannt sein müssen. Bei PCP dürfen Jobs 
keinen kritischen Abschnitt betreten, wenn es bereits gesperrte Semaphoren 
gibt, die diesen Job irgendwann blockieren könnten. Wenn ein Job einen kri- 
tischen Abschnitt betritt, kann er vor dem Verlassen desselben mithin nicht durch 
Jobs einer niedrigeren Priorität blockiert werden. Dies wird mit der Bildung eines 
Maximums von Prioritäten (engl. priority ceiling) erreicht. Jedem Semaphor S wird 
ein Maximum C(S) zugeordnet. Dies ist die statische Priorität des Jobs der höchsten 
Priorität, der S sperren kann. Das PCP-Protokoll geht wie folgt vor: 


e Wir nehmen an, dass Job J läuft und Semaphor S sperren möchte. Dann kann 
J S nur sperren, wenn die Priorität von J den Wert C(S’) des Semaphors S’ 
übersteigt, wobei S’ der Semaphor mit dem höchsten Wert von C(S) unter allen 
Semaphoren ist, die gegenwärtig durch von J verschiedene Jobs gesperrt werden. 
Wenn ein solcher Semaphor existiert, dann gilt J als durch S’ und den S’ haltenden 
Job blockiert. Wenn J durch S’ blockiert wird, erhält der Job, der S’ sperrt, die 
Priorität von J. 

e Wenn ein Job J einen kritischen Abschnitt, der durch S geschützt ist, verlässt, 
entsperrt er S. Sofern mindestens ein Job vorhanden ist, der durch S blockiert 
ist, wird unter diesen der Job der höchsten Priorität aufgeweckt. Die Priorität 
von J wird auf die höchste Priorität unter allen Jobs gesetzt, die noch durch eine 
Semaphore blockiert sind, die J hält. Wenn J durch keinen anderen Job blockiert 
wird, wird seine Priorität wieder auf seine normale Priorität zurückgesetzt. 


Beispiel 4.3: In der Abb. 4.11 werden Semaphore a, b und c benutzt®. Die höchste 
Priorität von a und b ist pı, die höchste Priorität von c ist p2. Zum Zeitpunkt h 
möchte Jz Semaphor c sperren, aber c ist schon gesperrt. Außerdem übersteigt die 
Priorität von Ja nicht den Wert C(c). Trotzdem resultiert der Versuch, c zu sperren, 
in einem Erhöhen der Priorität von J3 auf po. 

Zum Zeitpunkt ts versucht Jı, Semaphor a zu sperren. a ist noch nicht gesperrt, 
aber J3 hat b gesperrt und die gegenwärtige Priorität von J; übersteigt nicht den 
Wert C(b). Deswegen wird J; blockiert. Dies ist die wesentliche Eigenschaft von 
PCP: dieses Blockieren vermeidet ansonsten mögliche spätere Deadlocks. J3 erhält 
die Priorität von Jı. Darin drückt sich aus, dass J; darauf wartet, dass Semaphor b 
durch J3 freigegeben wird. 


8 Wir nutzen hier ein Beispiel von Bordoloi [59]. 
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Abb. 4.11 Sperren mit PCP 


Zum Zeitpunkt 16 entsperrt J3 Semaphor b. J; ist der Job der höchsten Priorität, 
der bislang durch b blockiert war und er wird jetzt wieder aufgeweckt. Die Priorität 
von J3 fällt auf p2. Jı sperrt und entsperrt a und b und wird zu Ende ausgeführt. 
Zum Zeitpunkt 77 ist J2 noch durch c blockiert und unter allen Jobs mit p2 ist J3 der 
einzige, der weiter ausgeführt werden kann. Zum Zeitpunkt tg entsperrt J3 Semaphor 
c und seine Priorität fällt auf p3. J2 ist nicht mehr länger blockiert und er verdrängt 
Jz und sperrt c. J3 wird erst wieder ausgeführt, wenn J2 beendet wurde. V 


Beispiel 4.4: Wir betrachten nunmehr ein Beispiel, das wir später für einen Vergleich 
mit einem erweiterten PCP-Protokoll verwenden werden. Abb. 4.12 zeigt dieses 
zweite Beispiel?. Die höchste Priorität unter allen Semaphoren ist die Priorität von 
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Abb. 4.12 Zweites PCP-Beispiel 


° Dieses Beispiel wurde [59] entnommen. 
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Jı. Zum Zeitpunkt t2 möchte J3 Semaphor c sperren, aber die Priorität von J3 ist 
kleiner als C(a) für die bereits gesperrte Semaphore a und J, erhält die Priorität von 
J3. Zum Zeitpunkt tz gibt es einen Sperrwunsch für b, aber die Priorität von J2 ist 
wieder kleiner als C(a) des bereits gesperrten Semaphors a und J4 erhält die Priorität 
von J2. Zum Zeitpunkt t5 gibt es einen Sperrwunsch für a, aber die Priorität von 
Jı übersteigt nicht C(a) und J4 erhält die Priorität von Jı. Nachdem J4 Semaphor 
a freigibt, ist kein Semaphor gesperrt und seine Priorität fällt auf seine normale 
Priorität. Zu dieser Zeit hat Jı die größte Priorität und wird bis zu seinem Ende 
ausgeführt. Die verbleibenden Ausführungen sind durch die normalen Prioritäten 
bestimmt. Vv 


Es kann gezeigt werden, dass PCP Deadlocks vermeidet (siehe [81], Theorem 
7.3). Es gibt Varianten von PCP, die sich dadurch von PCP unterscheiden, dass 
die Prioritäten zu anderen Zeitpunkten geändert werden. Das Distributed Priority 
Ceiling Protocol (DPCP) [466] und das Multiprocessor Priority Ceiling Protocol 
(MPCP) [465] sind Erweiterungen von PCP auf Multiprozessoren. 


4.2.4 Stack Resource Policy-Protokoll 


Im Unterschied zu PCP unterstützt die Stack Resource Policy (SRP) dynamisches 
Scheduling, insbesondere kann SRP mit den dynamischen Prioritäten benutzt wer- 
den, die im EDF-Scheduling berechnet werden (siehe Unterabschnitt 6.2.1 auf Seite 
332). Bei SRP müssen wir zwischen Jobs und Tasks unterscheiden. Tasks können 
sich wiederholende Berechnungen beschreiben (siehe auch Definition 2.2). Jede 
Berechnung bildet einen Job entsprechend unserer bisherigen Benutzung. Unter 
dem Begriff Task erfassen wir jetzt alle Eigenschaften, die auf eine Menge von 
gleichartigen Jobs zutreffen, d.h. Jobs, die periodisch denselben Code ausführen. 
Dementsprechend gehört zu jeder Task t; eine Menge von Jobs. Siehe dazu auch 
Definition 6.1 auf Seite 324. SRP betrachtet nicht jeden Job einer Task einzeln, 
sondern definiert Eigenschaften, die global auf Tasks Anwendung finden. Zusätz- 
lich unterstützt SRP Ressourcen, die aus mehreren Einheiten bestehen, wie z.B. 
Speicherpuffer. Die folgenden Größen werden definiert: 


e Der preemption level l; einer Task 7; gibt Informationen darüber, welche anderen 
Tasks durch Jobs von 7; verdrängt werden können. Eine Task Tr; kann eine andere 
Task 7; nur verdrängen, wenn l; > l; ist. Wir verlangen: Wenn Task 7; nach 7; 
im System ankommt und 7; hat eine höhere Priorität als t;, dann muss I; > 1; 
sein. Für EDF-Scheduling (siehe Seite 332) bedeutet dies, dass die preemption 
levels eine monoton fallende Folge der relativen Deadlines sind. Umso später die 
Deadline, umso leichter wird es sein, einen Job zu verdrängen. l; ist ein statischer 
Wert. 

e Die resource ceiling einer Ressource ist der größte preemption level der Tasks, die 
dadurch blockiert werden könnten, dass sie ihre Maximalforderung an Einheiten 
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dieser Ressource stellen. Die resource ceiling ist ein dynamischer Wert, der davon 
abhängt, wie viele Einheiten in den Ressourcen noch verfügbar sind. 

e Die system ceiling ist die größte unter allen resource ceilings von gegenwärtig 
blockierten Ressourcen. Dieser Wert ist dynamisch und ändert sich mit dem 
Zugriff auf Ressourcen. 


SRP blockiert Jobs nicht, wenn sie versuchen, eine Ressource zu blockieren, sondern 
wenn sie versuchen, andere zu verdrängen. 


Beispiel 4.5: Abb. 4.13! zeigt den Unterschied zwischen PCP und SRP anhand des 
Beispiels aus Abb. 4.12. Im Fall von SRP gibt es zum Zeitpunkt tı kein Verdrängen, 
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Abb. 4.13 Verhalten des SRP-Protokolls 


denn der preemption level ist nicht größer als die system ceiling. Dasselbe passiert 
zum Zeitpunkt t4. Insgesamt kommt es bei SRP zu deutlich weniger Verdrängungen 
von Jobs als bei PCP. Daher ist SRP ein sehr beliebtes Protokoll. V 


SRP heißt stack resource policy, da Jobs nicht durch Jobs mit einem niedrigeren 
preemption level blockiert werden können und sie können nur wieder ausgeführt 
werden, wenn der vorherige Job zu Ende ausgeführt wurde. Daher können alle Jobs 
mit demselben l; denselben Stack-Speicherplatz belegen. Bei sehr vielen Jobs mit 
demselben preemption level kann so viel Speicherplatz gespart werden. SRP ist auch 
frei von Deadlocks (siehe Baker [34]). Buttazzo [81] beschreibt weitere Details von 
SRP. 

PIP-, PCP- und SRP-Protokolle wurden für Einzelprozessoren entworfen. Raj- 
kumar et al. [466] haben eine erste Übersicht über Protokolle für den Zugriff zu 
Ressourcen bei Multiprozessoren veröffentlicht. Gegenwärtig hat sich hierfür noch 
kein Standard etabliert (siehe Baruah et al. [38], Kapitel 23). 


10 Auch diese Abbildung wurde [59] entnommen. 
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4.3 ERIKA 


Verschiedene eingebettete Systeme (wie Automobilsteuergeräte und Haushaltsge- 
räte) bedingen, dass die gesamte Anwendung auf einem kleinen Mikrocontroller 
integriert ist!!. Daher müssen die von der Firmware angebotenen Betriebssystem- 
dienste auf solchen Systemen auf eine solche minimale Teilmenge beschränkt wer- 
den, welche die mehrfädige Ausführung von periodischen und aperiodischen Tasks 
unterstützt und dabei gemeinsame Ressourcennutzung unter Vermeidung von Prio- 
ritätsumkehr erlaubt. 

Entsprechende Anforderungen wurden in den neunziger Jahren durch das OSEK/ 
VDK-Konsortium veröffentlicht [578]. Diese definierten die minimale Menge an 
Diensten eines mehrfädigen Echtzeitbetriebssystems, die mit einer Codegröße von 
1-10 kB auf einem 8-Bit Mikrocontroller implementierbar sein sollte. Im Jahr 2010 
wurde die OSEK/VDX API durch das AUTOSAR-Konsortium [27] um Funktionali- 
tät zur Unterstützung von zeitlichem Schutz, Scheduling-Tabellen für zeitgetriggerte 
Systeme und Speicherschutz zum Schutz der Ausführung unterschiedlicher An- 
wendungen auf demselben Mikrocontroller erweitert. Dieser Abschnitt beschreibt 
in Kürze die Haupteigenschaften von und Anforderungen an solche Systeme, wo- 
bei der Open Source-Echtzeitkern ERIKA Enterprise als Referenzimplementierung 
dient [157]. 

Die erste Eigenschaft, die einen OSEK-Kern von anderen Betriebssystemen un- 
terscheidet, ist, dass alle Kernobjekte statisch zur Übersetzungszeit definiert sind. 
Insbesondere erlauben die meisten dieser Systeme weder dynamische Speicherzu- 
teilung noch die dynamische Erzeugung von Tasks!?. Um den Benutzer bei der 
Konfiguration des Systems zu unterstützen, stellt der OSEK/VDX-Standard die 
Konfigurationssprache OIL zur Verfügung, in der die für die Anwendung zu in- 
stanziierenden Objekte definiert werden. Beim Übersetzen der Anwendung erzeugt 
der OIL-Compiler die Betriebssystem-Datenstrukturen und alloziert genau die be- 
nötigte Menge an Speicher. Dieser Ansatz ermöglicht es, nur genau die Daten im 
Flash-Speicher (der bei den meisten Mikrocontrollern preiswerter als RAM ist) zu 
allozieren, die von der Anwendung wirklich gebraucht werden. 

Das zweite Unterscheidungsmerkmal eines OSEK/V DX-Systems im Vergleich zu 
Standard-Betriebssystemen ist die Unterstützung für gemeinsam benutzte Stapel 
(engl. Stack Sharing). Stack Sharing wird eingesetzt, da RAM-Speicher bei kleinen 
Mikrocontrollern sehr teuer ist. Ob Stack Sharing einsetzbar ist, hängt insbesondere 
davon ab, wie der Code der einzelnen Tasks geschrieben wurde. 

In herkömmlichen Echtzeitsystemen ist die Implementierung einer periodischen 
Task nach dem folgenden Schema strukturiert: 


task(x) { 
int Lokale_Variable; 
Initialisierung(); 
for (;;) { 


1 Dieser Abschnitt wurde von G. Buttazzo und P. Gai (Pisa) beigesteuert. 
12 Im Kontext von ERIKA wird der Begriff Task ähnlich benutzt wie bisher der Begriff Prozess. 
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Bearbeite_Instanz(); 
Ende_der_Instanz(); 
} 
J 


Dieses Schema ist gekennzeichnet durch eine Endlosschleife, die eine Instanz der pe- 
riodischen Task enthält, die mit einer blockierenden Operation Ende_der_Instanz() 
endet. Diese blockiert die Task bis zur nächsten Aktivierung. Wenn ein solches Pro- 
grammierschema zum Einsatz kommt (bei OSEK/VDX extended task genannt), ist 
diese Task ständig, auch in Wartezeiten, auf dem Stapel präsent. In diesem Fall kann 
der Stapel nicht geteilt werden und es muss ein eigener Stapel-Bereich für jede Task 
reserviert werden. 

Der OSEK/VDX-Standard sieht außerdem basic tasks vor. Diese sind periodische 
Tasks, die ähnlich zu Funktionen nach dem folgenden Schema implementiert werden: 


int Lokale_Variable; 
task(x) { 
Bearbeite_Instanz(); 


} 
System_Initialisieren() { 
Initialisierung(); 


} 


Im Vergleich zu extended tasks wird in basic tasks der persistente Zustand, der 
zwischen zwei Ausführungen erhalten bleiben muss, nicht auf dem Stapel, sondern 
in globalen Variablen gespeichert. Der Initialisierungsteil wird in die Systeminitia- 
lisierung verschoben, da Tasks nicht dynamisch erzeugt werden, sondern schon zum 
Start des Systems existieren. Schließlich wird keine Synchronisierungsoperation be- 
nötigt, um die Task bis zu ihrer folgenden Periode zu blockieren, da die Task jedes 
Mal aktiviert wird, wenn eine neue Instanz startet. Die Task selbst kann auch keine 
blockierende Operation aufrufen, daher kann sie entweder von höher priorisierten 
Tasks verdrängt werden oder bis zu ihrem Ende ablaufen. So verhält sich die Task 
wie eine Funktion, die einen Bereich auf dem Stapel (engl. stack frame) alloziert, 
abläuft und dann den Bereich wieder freigibt. Daher belegt die Task keinen Sta- 
pelspeicher zwischen zwei Ausführungen und der Stapel kann von allen Tasks des 
Systems zusammen benutzt werden. ERIKA Enterprise unterstützt Stack Sharing 
für alle basic tasks des Systems, damit für diesen Anwendungsfall die Menge an 
benötigtem RAM-Speicher reduziert werden kann. 

Im Bereich der Taskverwaltung bieten OSEK/VDX-Kerne Unterstützung für 
Scheduling mit festen Prioritäten mit Immediate Priority Ceiling Protocol (deutsch 
unverzügliches Prioritäts-Obergrenzen-Protokoll), um Prioritätsumkehr-Probleme 
zu vermeiden. Die Verwendung des Immediate Priority Ceiling-Protokolls wird un- 
terstützt, indem der Ressourcenverbrauch jeder Task in der OIL-Konfigurationsdatei 
angegeben wird. Basierend auf dieser Angabe berechnet der OIL-Compiler den 
maximalen Ressourcenverbrauch für jede Task. 
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OSEK/VDX-Systeme unterstützen auch nicht verdrängendes (engl. non-preemp- 
tive) Scheduling und Präemptionsgrenzen, um den Gesamt-Stapelverbrauch zu be- 
grenzen. Hierbei ist der grundlegende Gedanke, dass eine Einschränkung der Ver- 
drängung zwischen Tasks die Anzahl der gleichzeitig auf dem Systemstapel allo- 
zierten Tasks reduziert, wodurch der Gesamtspeicherverbrauch weiter sinkt. Hierbei 
muss aber bedacht werden, dass eine Reduktion der Verdrängungen die Planbarkeit 
(engl. Schedulability) der Taskmengen verschlechtern kann, daher muss der Grad der 
Verdrängung gegen die Planbarkeit des Systems und den gesamten RAM-Verbrauch 
des Systems abgewogen werden. 

Eine weitere Anforderung an Betriebssysteme für kleine Mikrocontroller ist die 
Skalierbarkeit durch die Unterstützung reduzierter Versionen der API für Imple- 
mentierungen mit kleinerem Speicherverbrauch. Bei in großen Mengen produzierten 
Systemen beeinflusst dieser Speicherverbrauch in der Tat wesentlich die gesamten 
Systemkosten. In diesem Kontext wird Skalierbarkeit durch das Konzept der Con- 
formance Classes realisiert, die bestimmte Teilmengen der Betriebssystem-API de- 
finieren. Zu den Conformance Classes gehört ein definierter Weg, auf eine Klasse 
mit mehr Funktionalität zu wechseln. Dabei ist das Ziel, partielle Implementie- 
rungen des Standards mit reduziertem Speicherverbrauch zu unterstützen. Die vom 
OSEK/VDX-Standard (und damit von ERIKA Enterprise) unterstützten Conforman- 
ce Classes sind im Einzelnen: 


e BCCI: Dies ist die kleinste Conformance Class, sie unterstützt ein Minimum von 
8 Tasks mit unterschiedlicher Priorität und eine gemeinsame Ressource. 

e BCC2: Diese Conformance Class erweitert BCC1 um die Möglichkeit, mehr 
als eine Task mit derselben Priorität zu verwenden. Jede Task kann ausstehende 
Aktivierungen besitzen, d.h. das Betriebssystem führt über die Anzahl der schon 
aktivierten, aber noch nicht ausgeführten Instanzen Buch. 

e ECCI: Diese Conformance Class fügt der Klasse BCC1 die Möglichkeit hinzu, 
erweiterte Tasks zu verwenden, die auf das Eintreten eines Ereignisses warten 
können. 

e ECC2: Diese Conformance Class verfügt sowohl über mehrfache Aktivierungen 
wie über erweiterte Tasks. 


ERIKA Enterprise erweitert diese Conformance Classes durch die Bereitstellung 
der folgenden beiden Conformance Classes: 


° EDF: Diese Conformance Class verwendet einen Earliest Deadline First (EDF)- 
Scheduler, der für den Einsatz auf kleinen Mikrocontrollern optimiert wurde, 
anstelle eines Schedulers mit festen Prioritäten (siehe Abschnitt 6.2.1). 

e FRSH: Diese Conformance Class erweitert den EDF-Scheduler durch einen 
Ressourcen-Reservierungs-Scheduler, der auf dem IRIS Scheduling-Algorithmus 
basiert [381]. 


Eine weitere interessante Eigenschaft von OSEK/VDX-Systemen ist es, dass das 
System eine API zur Unterbrechungskontrolle zur Verfügung stellt. Dies ist ein 
großer Unterschied im Vergleich zu POSIX-basierten Systemen, in denen Unter- 
brechungen ausschließliche Aufgabe des Betriebssystems sind und nicht über eine 
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Betriebssystem-API zur Verfiigung gestellt werden. Der Grund hierfiir ist, dass die 
Benutzer kleiner Mikrocontroller oft Unterbrechungsprioritäten direkt kontrollieren 
möchten; daher ist es wichtig, eine Standardmethode zur Aktivierung und Deak- 
tivierung von Unterbrechungen zur Verfügung zu stellen. Zudem spezifiziert der 
OSEK/VDX-Standard zwei Arten von Unterbrechungsbehandlungsroutinen (engl. 
Interrupt Service Routines (ISR)): 


e Kategorie 1: einfacher und schneller, implementiert keinen Aufruf des Schedulers 
am Ende der ISR; 

e Kategorie 2: diese ISR kann einige Funktionen aufrufen, die das Scheduling- 
Verhalten ändern. Am Ende der ISR kann Scheduling stattfinden. ISR1 hat stets 
eine höhere Priorität als ISR2. 


Eine wichtige Eigenschaft von OSEK/VDX-Kernen ist die Möglichkeit, den Spei- 
cherverbrauch genau zu kontrollieren. Dazu kann aus Produktionsversionen Code 
zur Fehlerüberprüfung entfernt werden, zudem sind spezielle Einsprungpunkte (engl. 
hooks) vorgesehen, die vom System aufgerufen werden, wenn bestimmte Ereignisse 
auftreten. Diese Eigenschaften erlauben es, den Speicherverbrauch einer Anwen- 
dung präzise zu steuern; die während des Debugging genutzte Version ist größer 
(und sicherer), während die Produktionsversion kleiner ist, da zu diesem Zeitpunkt 
die meisten Fehler im Code bereits gefunden und beseitigt sein sollten. 

Der OSEK/VDX-Standard unterstützt eine Sprache namens ORTI, um die De- 
bugging-Möglichkeiten zu verbessern. Diese Sprache enthält eine Beschreibung, an 
welchen Speicherstellen die verschiedenen Objekte des Betriebssystems alloziert 
wurden. Die ORTI-Datei wird normalerweise vom OIL-Compiler erzeugt. Sie wird 
von Debuggern genutzt, um detaillierte Informationen über im System definierte 
Betriebssystemobjekte anzuzeigen (beispielsweise könnte der Debugger eine Liste 
aller Tasks im System zusammen mit ihrem jeweiligem Status ausgeben). 

Alle vom OSEK/VDX-Standard definierten Eigenschaften wurden im Open Sour- 
ce-Kern ERIKA Enterprise implementiert [157]. Zielplattform ist eine Reihe von 
Mikrocontrollern. Die endgültige Codegröße schwankt dabei zwischen 1 und 5 Ki- 
lobyte Objektcode. ERIKA Enterprise implementiert auch weitere Eigenschaften, 
wie den EDF-Scheduler, und stellt damit ein offenes und kostenloses Betriebssystem 
zur Verfügung, das zum Lernen, zum Testen und auch zum Implementieren echter 
Anwendungen für Industrie- und Lehrzwecke eingesetzt werden kann. 


4.4 Linux für eingebettete Systeme 


Die Anforderungen an die Funktionalität eingebetteter Systeme steigen zusehends. 
Beispiele hierfür sind Netzwerkkonnektivität (besonders für das Internet der Dinge) 
oder anspruchsvolle Grafikanzeigen. Zur Realisierung dieser Funktionalität muss 
ein typisches eingebettetes Betriebssystem durch eine große Menge an Software 
erweitert werden. Teile dieser komplexen Funktionen können auch in kleine einge- 
bettete Betriebssysteme integriert werden, wie z.B. ein kleiner Internetprotokollstack 
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[142]. Die Integration mehrerer zusätzlicher Softwarekomponenten stellt aber eine 
komplexe Aufgabe dar und kann zu Beeinträchtigungen der Funktion wie auch der 
Sicherheit eines Systems führen. 

Ein anderer Ansatz, der durch das exponentielle Wachstum von Komponenten- 
dichten in Halbleitern nach dem Mooreschen Gesetz ermöglicht wird, ist die Anpas- 
sung eines Softwaresystems, das die gewünschte Funktionalität bereits enthält und 
in einer großen Vielfalt von Umgebungen getestet wurde, an eingebettete Systeme. 
In diesem Bereich hat sich Linux! als Betriebssystem der Wahl für eine große Zahl 
komplexer eingebetteter Anwendungen etabliert. Beispiele für diese Anwendun- 
gen sind Internetrouter, GPS-Navigationssysteme, Netzwerkspeicher, Fernsehgeräte 
mit Internet-Zusatzfunktionen (sogenannte ,, Smart-TVs”’) und Mobiltelefone. Diese 
Anwendungen profitieren davon, dass Linux einfach portierbar ist. Das System ist 
mittlerweile für mehr als 30 Prozessorarchitekturen verfügbar, wie z.B. die in ein- 
gebetteten Systemen verbreiteten ARM-, MIPS- und PowerPC-Architekturen. Des 
Weiteren bringt Linux den Vorteil mit sich, durch seine Verfügbarkeit unter freien 
Softwarelizenzen die ansonsten anfallenden Lizenzkosten für kommerzielle einge- 
bettete Systeme einzusparen. 


4.4.1 Struktur und Größe von Linux für eingebettete Systeme 


Genau genommen bezeichnet der Begriff „Linux” nur den eigentlichen Kern eines 
Linux-basierten Betriebssystems. Ein komplettes, funktionierendes Betriebssystem 
benötigt eine Menge an zusätzlichen Komponenten, die auf dem Linux-Kern auf- 
bauen. Die Konfiguration eines typischen Linux-Systems, das auch die systemnahen 
Komponenten außerhalb des Kerns beinhaltet, ist in Abb. 4.14 dargestellt. Ober- 
halb des Linux-Kerns finden sich — meist dynamisch gelinkte — Bibliotheken, die 
grundlegende Funktionen für Systemwerkzeuge und Anwendungen bereitstellen. 
Gerätetreiber werden in Linux üblicherweise als dynamisch ladbare Kernmodule 
realisiert, ein direkter Zugriff von Anwendungen auf die Hardware ist aber auch 
möglich. 

Die Verfügbarkeit des Linux-Quellcodes ermöglicht es, den Kern und andere Sys- 
temkomponenten an die Anforderungen einer gegebenen Anwendung und Plattform 
anzupassen. Daraus folgt, dass auch kleine Linux-Systeme realisierbar sind, die auf 
Systemen mit wenig Hauptspeicher genutzt werden können. 

Eine der zentralen Komponenten eines Unix-artigen Systems wie Linux ist die C- 
Bibliothek libc. Diese stellt grundlegende Funktionen wie z.B. Datei-Ein/Ausgabe, 
Prozesssynchronisation und -kommunikation, Behandlung von Zeichenketten, arith- 
metische Operationen und Speicherverwaltung zur Verfügung. Die normalerweise 
in Linux verwendete Variante ist die GNU libc (glibc). Diese wurde für Server- und 
Desktop-Systeme entwickelt und stellt daher deutlich mehr Funktionalität zur Ver- 
fügung als normalerweise in eingebetteten Systemen benötigt wird. Linux-basierte 


13 Dieser Abschnitt zu Linux in eingebetteten Systemen wurde von M. Engel (NTNU Trondheim) 
beigesteuert. 


4.4 Linux fiir eingebettete Systeme 245 


Systembibliotheken (z.B. libc) 
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treiber Gerätespez. Code IPC 


| 
Architekturabhängiger Code 


Abb. 4.14 Struktur eines typischen Linux-Systems 


Android®-Systeme verwenden anstelle von libc die Bionic-Bibliothek, die von BSD- 
Unix-Varianten abgeleitet ist. Bionic ist dafür entworfen worden, Systeme mit gerin- 
gerer Rechenleistung zu unterstützen. Dies geschieht z.B. durch die Bereitstellung 
einer maßgeschneiderten Version der pthreads Multithreading-Bibliothek, die effi- 
zient die in Android verwendete Java-VM Dalvik unterstützt. Die Codegröße von 
Bionic beträgt ungefähr die Hälfte einer typischen glibc-Version!*. 


libc-Version musl| uClibc| dietlibc glibc 
Größe der statischen Bibliothek 426 kB| 500kB| 120kB| 2.0 MB 
Größe der dynamischen Bibliothek 527 kB| 560kB| 185kB| 7,9 MB 
Minimale Größe C-Programm, statisch gelinkt 1,8 kB 5kB| 0,2kB| 662 kB 
Minimale Größe „Hello, World”, statisch gelinkt 13 kB 70 kB 6 kB| 662 kB 


Abb. 4.15 Größenvergleich verschiedener libc-Konfigurationen für Linux 


Daneben existieren aber auch weitere deutlich kleinere Implementierungen der 
C-Bibliothek, wie z.B. newlib, musl, uClibc, PDCLib und dietlibc. Jede dieser 
Varianten ist für einen bestimmten Anwendungsfall optimiert, so ist z.B. musl für 
den Einsatz in statisch gelinkten Programmen optimiert. uClibc wurde ursprünglich 
für Linux-Systeme ohne Speicherverwaltungseinheit (MMU)'> entwickelt, wogegen 
newlib eine plattformunabhängige C-Bibliothek ist, die auch für verschiedene andere 
Betriebssystemplattformen verfügbar ist. Die Größen der zugehörigen Binärdateien 


14 Die Größe der glibc-Bibliothek beinhaltet allerdings umfangreichere Unterstützung für Interna- 
tionalisierung. 


15 Eine Einführung in MMUs findet sich in Anhang C. 
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bewegen sich im Bereich von 185 kB (dietlibc) bis 560 kB (uClibc). Im Vergleich 
dazu beträgt die typische Größe der glibc 7,9 MB (alle Werte beziehen sich auf die 
x86-Versionen)!®. Abb. 4.15 gibt einen Überblick über die Größen verschiedener 
libc-Varianten und damit übersetzter Programme. 

Neben der C-Bibliothek kann auch die Funktionalität, Größe und Anzahl der 
mit dem Betriebssystem mitgelieferten Systemprogramme an die Anforderungen 
der jeweiligen Anwendung angepasst werden. Diese Programme werden in Linux 
zur Steuerung des Systemstarts und -betriebs sowie zur Systemüberwachung be- 
nötigt, z.B. in Programmen zum Einbinden eines Dateisystems, zur Konfiguration 
von Netzwerkschnittstellen oder zum Kopieren von Dateien. Wie glibc enthält auch 
ein Linux-System selbst eine Menge an Programmen, die für eine große Anzahl 
verschiedener Anwendungsfälle gedacht sind, in den meisten Fällen aber für einge- 
bettete Systeme nicht notwendig sind. 

Eine Alternative zu dieser Menge an diversen Programmen ist BusyBox, eine 
Software, die eine Reihe von vereinfachten essentiellen Unix-Werkzeugen in einer 
einzigen ausführbaren Datei vereint. BusyBox wurde speziell für eingebettete Sys- 
teme mit sehr begrenzten Ressourcen entwickelt. Sie reduziert den zusätzlichen 
Speicherbedarf des ausführbaren Dateiformats und ermöglicht, dass Code von meh- 
reren Anwendungen ohne Verwendung einer Bibliothek geteilt wird. Ein Vergleich 
von BusyBox mit weiteren Ansätzen, eine Menge an kleinen Werkzeugen für den 
Systembetrieb zur Verfügung zu stellen, findet sich unter [531]. 


4.4.2 Echtzeiteigenschaften 


Eine der komplexesten Herausforderungen bei der Anpassung eines Allzweck- 
Betriebssystemkerns für eingebettete Systeme ist die Einhaltung von Echtzeitei- 
genschaften. Wie bereits in Abb. 4.3 dargestellt, ist ein verbreiteter Ansatz hierzu, 
den Linux-Kern und alle Linux-Prozesse als dedizierte Task eines darunterliegen- 
den Echtzeitbetriebssystems auszuführen, die nur aktiv ist, wenn keine Echtzeittask 
Rechenzeit benötigt. Für Linux existieren verschiedene Implementierungen, die die- 
sen Ansatz realisieren. RTAI (real-time application interface) [138] basiert auf 
dem Adeos-Hypervisor!’, der als Linux-Kernerweiterung implementiert ist. Ade- 
os ermöglicht es, verschiedene priorisierte Domänen, wovon eine der Linux-Kern 
selbst ist, zeitgleich auf derselben Hardware auszuführen. Darauf basierend stellt 
RTAI eine Diensteschnittstelle (engl. Application Programmer Interface (AP])) zur 
Verfügung, die z.B. die Steuerung von Unterbrechungen und Systemzeitgebern er- 
möglicht. Xenomai [182] wurde einige Jahre lang gemeinsam mit RTAI entwi- 
ckelt, bis es im Jahr 2005 ein eigenständiges Projekt wurde. Es basiert auf einem 
abstrakten „nucleus”-Echtzeitkern, der Funktionalitäten wie Echtzeit-Scheduling, 
Zeitgeber, Speicherverwaltung und virtuelle Dateisysteme zur Verfügung stellt. Die 


16 Die Werte entstammen einem umfassenden Vergleich verschiedener libc-Varianten von Eta Labs, 
verfügbar unter http://www.etalabs.net/compare_libcs.html. 


17 Siehe http://home.gna.org/adeos/. 
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beiden Projekte unterscheiden sich in ihren Zielen und ihrer Implementierung. Al- 
lerdings unterstiitzen beide das Real-Time Driver Model (RTDM), einen Ansatz zur 
Vereinheitlichung von Schnittstellen fiir Gerätetreiber und darauf basierender An- 
wendungen für echtzeitfähige Linux-Systeme. Der dritte Ansatz, der ebenfalls einen 
unterliegenden Echtzeitkern verwendet, ist RTLinux [608], das als Projekt am New 
Mexico Institute of Mining and Technology entwickelt und später von der Firma 
FSMLabs, die im Jahr 2007 von WindRiver übernommen wurde, kommerzialisiert 
wurde. Das zugehörige Produkt wurde bereits im Jahr 2011 eingestellt. Der Ein- 
satz von RTLinux in Produkten wurde kontrovers diskutiert, da dessen Erfinder ihr 
geistiges Eigentum, für das sie ein Software-Patent [607] erhielten, vehement ver- 
teidigten. Die Entscheidung, die Methoden hinter RTLinux zu patentieren, rief bei 
Linux-Entwicklern wenig Begeisterung hervor, was schließlich zur Entwicklung der 
oben erwähnten alternativen Projekte RTAI und Xenomai führte. 

Ein neuerer Ansatz, Linux um Echtzeitfähigkeiten zu erweitern, ist SCHED_DEAD- 
LINE, das seit 2014 (Kernversion 3.14) im Linux-Kern integriert ist. Dabei handelt 
es sich um ein CPU-Scheduling-Verfahren, das auf den Algorithmen für Earliest 
Deadline First (EDF) und Constant Bandwidth Server (CBS) [3] basiert und die 
Reservierung von Ressourcen unterstützt. Das SCHED_DEADLINE-Verfahren kann da- 
bei gemeinsam mit anderen Linux Scheduling-Verfahren aktiv sein, es hat aber stets 
Vorrang vor allen anderen Verfahren, um Echtzeiteigenschaften garantieren zu kön- 
nen. 

Jede unter SCHED_DEADLINE eingeplante Task 7; erhält ein Laufzeit-Budget C; und 
eine Periode 7;. Dies zeigt dem Kern an, dass diese Task in einer Periode T; jeweils 
C; Zeiteinheiten auf einem beliebigen Prozessor benötigt. Bei Echtzeitanwendungen 
entspricht 7; der minimalen Zeit zwischen zwei aufeinanderfolgenden Aktivierungen 
der Task, C; entspricht der WCET für jede Ausführung der Task. Wenn eine neue 
Task zum Scheduling-Verfahren hinzugefügt werden soll, wird ein Test auf Einplan- 
barkeit (schedulability) durchgeführt. Die Task wird nur akzeptiert, wenn der Test 
erfolgreich ist. Während des Schedulings wird eine Task suspendiert und auf die 
kommende Periode verlagert, wenn sie versucht, mehr Rechenzeit zu beanspruchen 
als ihrem Budget entspricht. Diese sogenannte non-work conserving-Strategie!® ist 
notwendig, um die temporale Isolation zwischen Tasks sicherzustellen. Daher ist 
auf Einprozessorsystemen und partitionierten Mehrprozessorsystemen (mit Tasks, 
deren Ausführung auf eine bestimmte CPU beschränkt ist) für alle akzeptierten 
SCHED_DEADLINE-Tasks garantiert, dass sie für eine Gesamtzeit eingeplant werden, 
die ihrem Zeitbudget in jedem Zeitfenster entspricht. 

Für den allgemeinen Fall, in dem Tasks zwischen verschiedenen Kernen eines 
Mehrprozessorsystems migrieren können, gilt die übliche tardiness-Grenze für glo- 
bales EDF [128], da SCHED_DEADLINE globales EDF implementiert (wie im Detail 
in Abschnitt 6.3.3 beschrieben). Benchmarks aus [337] geben den Anteil verpasster 
Deadlines mit weniger als 0,2% an, wenn SCHED_DEADLINE auf einem Vierprozes- 
sorsystem mit einer Auslastung von 380% läuft und von weniger als 0,615% bei 
einer Auslastung von 390%. Die angegebenen Zahlen für ein Sechsprozessorsystem 


18 Dies bedeutet, dass der Prozessor idle sein kann, auch wenn Tasks ausgeführt werden könnten. 
Eine Definition des Begriffs findet sich in Kapitel 6 auf Seite 336. 
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liegen in einer ähnlichen Größenordnung. Selbstverständlich treten bei Einprozes- 
sorsystemen und Systemen, bei denen eine Task an einen Prozessorkern gebunden 
wurde, keine verpassten Deadlines auf. 


4.4.3 Dateisysteme für Flash-Speicher 


Die Anforderungen eingebetteter Systeme an permanenten Speicher unterscheiden 
sich von denen im Server- und Desktop-Bereich. Oft existiert eine große Menge an 
statischen (nur-lese) Daten, wogegen die Menge an variablen Daten in vielen Fällen 
sehr gering ist. 

Dateisysteme können sich diese besonderen Bedingungen zu Nutze machen. Da 
ein Großteil der nur-lese-Daten in aktuellen eingebetteten Systemen als Flash-ROM 
realisiert ist, ist die Optimierung für diese Art von Speicher ein wichtiger Aspekt 
bei der Nutzung von Linux in eingebetteten Systemen. Daher wurden eine Reihe 
verschiedener Dateisysteme entwickelt, die speziell für die Nutzung von NAND- 
Flash basierten Speichern ausgelegt sind. 

Eines der stabilsten Flash-spezifischen Dateisysteme ist das protokollbasierte 
Journaling Flash File System version 2 (JFFS2) [596]. JFFS2 protokolliert Ände- 
rungen an Dateien und Verzeichnissen im Flash-Speicher in Knoten (nodes). Es gibt 
zwei Arten von Knoten. /nodes (dargestellt in Abb. 4.16) bestehen aus einem Header 
mit Datei-Metadaten, gefolgt von optionalen Dateiinhalten, wogegen dirent-Knoten 
Verzeichniseinträge darstellen, die jeweils einen Namen und die Nummer einer ino- 
de beinhalten. Knoten werden bei ihrer Erzeugung als gültig markiert und verlieren 
ihre Gültigkeit, wenn eine neuere Version an einer anderen Stelle im Flash-Speicher 
erzeugt wurde. JFFS2 unterstützt die transparente Kompression von Daten durch die 
Speicherung komprimierter Daten als Nutzdaten der inodes. 


Gemeinsamer Header für Knoten Knotenspezifischer Inhalt 
f Gesamte Knotenheader een 
Bitmaske Knotentyp Knotenlange CRC Inode/Verzeichniseintrag 


0x1985 


Abb. 4.16 Inhalt einer JFFS2-Inode 


Verglichen mit anderen protokollbasierten Dateisystemen wie Berkeley lfs [473] 
existiert in JFFS2 allerdings kein zirkuläres Protokoll. Stattdessen verwendet JFFS2 
Blöcke, die der Größe der löschbaren Segmente des unterliegenden Flash-Speichers 
entsprechen. Wie in Abb. 4.17 gezeigt, werden Blöcke einzeln vom Start des Blocks 
ab mit Knoten gefüllt. 

Bereinigte (clean) Blöcke enthalten ausschließlich gültige Knoten, wogegen un- 
bereinigte (dirty) Blöcke mindestens einen ungültigen (veralteten) Block beinhalten. 
Um Speicher freizugeben, sammelt ein Dienst zur automatischen Speicherbereini- 
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In den Flash-Speicher geschriebene Knoten 


Verzeichniseintrag-Knoten 


2 Nummer der 
Benutzeraktionen Version Inode-Nummer Sarnen Name 
Öffne Datei und 001 0x10 0x0 Filename.txt 
schreibe 512 Bytes : 
'aaaaa...' an Offset 0 inode-Knoten 
Version Offset Länge Daten 
001 0x00 0x200 aaaaa... 
inode-Knoten 
Version Offset Lange Daten 
Schreibe 6 kB 002 0x200 0x1000 bbbbb... 
'bbbbb...' an ; 
ode-Knot 
Offset 512 Bene 
Version Offset Länge Daten 
003 0x1200 0x800 bbbbb... 
inode-Knoten 
Schreibe 1 kB Version Offset Length Data 
'ccccc...' an 
Offset 256 004 0x100 0x400 cccce... 


Abb. 4.17 Änderung des Flash-Inhalts bei Schreibvorgängen in JFFS2 


gung (engl. garbage collector) die unbereinigten Blöcke im Hintergrund ein und gibt 
diese wieder frei. Gültige Knoten aus unbereinigten Blöcken werden dabei in neue 
Blöcke kopiert und ungültige übersprungen. Nach dem Ende des Kopiervorgangs 
wird der unbereinigte Block als freigegeben markiert. Der garbage collector kann 
auch bereinigte Blöcke nutzen, um die Abnutzung des Flash-Speichers gleichmäßig 
zu gestalten (engl. wear-leveling). Damit wird vermieden, dass Blöcke wiederholt in 
einem beschränkten kleinen Bereich eines größtenteils statischen Dateisystems, wie 
es oft in eingebetteten Systemen der Fall ist, gelöscht werden. 


4.4.4 Verringerung des Hauptspeicherbedarfs 


Traditionell sehen Unix-ähnliche Systeme den Hauptspeicher (RAM) als einen Cache 
für Sekundärspeicher auf einer Festplatte, d.h. Auslagerungsspeicher (engl. swap 
space), an [386]. Dies ist eine sinnvolle Annahme für Server- und Desktop-Systeme 
mit großen Festplatten und entsprechend großem Speicherbedarf. Bei eingebetteten 
Systemen führt dies jedoch zu einer Verschwendung von Ressourcen, da Programme, 
die im nichtflüchtigen Speicher eines Systems abgelegt sind, vor ihrer Ausführung 
zunächst in den flüchtigen Hauptspeicher kopiert werden müssen. Dies trifft auch 
auf den üblicherweise recht großen Betriebssystemkern selbst zu. 
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Um diesen doppelten Speicherbedarf zu vermeiden, wurden verschiedene Tech- 
niken zur direkten Ausführung von Programmcode aus Festwertspeichern (engl. 
Execute-in-Place (XiP)) entwickelt. Diese Technik ist bei kleineren mikrocontrol- 
lerbasierten Systemen üblich, bringt aber einige Probleme mit sich. Zum Einen muss 
der nichtflüchtige Speicher, der das auszuführende Programm beinhaltet, Zugriffe 
mit Byte- oder Wort-Granularität unterstützen. Zum Anderen werden ausführbare 
Programme meist in einem Datenformat wie ELF gespeichert, das Metainforma- 
tionen (z.B. Symbole für Debugging) beinhaltet und vor der Ausführung zunächst 
gelinkt werden muss. 

Die Unterstützung für XiP-Techniken wird meist als eigenes Dateisystem im- 
plementiert, z.B. beim Advanced XiP Filesystem (AXFS) [42], das zusätzlich die 
Kompression von nur-lese-Daten erlaubt. Die Verwendung von XiP ist besonders 
für den Linux-Kern selbst nützlich, da dieser normalerweise eine große Menge an 
nicht auslagerbarem Speicher belegt. Die Ausführung des Kerns direkt aus dem 
Flash lässt entsprechend mehr Hauptspeicher für Benutzerprozesse übrig. XiP für 
Benutzerprozesse selbst ist weniger nützlich, da der Linux-Kern in Systemen mit vir- 
tuellem Speicher jeweils nur die benötigten Speicherseiten einer ausführbaren Datei 
in den Hauptspeicher lädt. Dadurch wird der RAM-Bedarf für diese Programme 
automatisch minimiert. 

Die Verfügbarkeit von Flash-Speicher mit byte- oder wortgranularem Zugriff, 
wie für XiP benötigt, ist für aktuelle Systeme zumeist eine Kostenfrage. Die übli- 
cherweise verwendete NAND-Flash-Technologie, die z.B. in SD-Speicherkarten und 
SSDs zum Einsatz kommt, ist kostengünstig, erlaubt aber jeweils nur blockweisen 
Zugriff, ähnlich wie konventionelle Festplatten. NOR-Flash hingegen ist eine Tech- 
nologie, die wahlfreien Zugriff erlaubt und die sich damit für die Implementierung 
von XiP-Techniken eignet. Allerdings ist NOR-Flash meist eine Größenordnung 
teurer als NAND-Flash und zudem langsamer als RAM-basierter Hauptspeicher. 
Entsprechend kann es für viele Systeme eine sinnvolle Entwurfsentscheidung sein, 
einen größeren RAM-Speicher anstelle von NOR-Flash-basierten XiP-Techniken zu 
verwenden. 


4.4.5 uClinux — Linux für Systeme ohne MMU 


Eine weitere Ressourcenbeschränkung findet sich schließlich in kleineren mikrocon- 
trollerbasierten Systemen wie der Cortex-M-Serie von ARM. Die Prozessorkerne 
in diesen Systemen wurden für den Einsatz mit typischen Echtzeitbetriebssystemen 
entwickelt, die oft der einfachen Struktur eines Bibliotheks-Betriebssystems ent- 
sprechen, wie für Erika (siehe Seite 240) beschrieben. Daher fehlt diesen Mikrocon- 
trollern wichtige Hardware zur Unterstützung von Betriebssystemen, speziell eine 
Speicherverwaltungseinheit (engl. memory management unit (MMU), siehe Anhang 
C). Mit einigen Einschränkungen ist es aber möglich, Linux auf Mikrocontrollern mit 
ausreichend großem Speicher und vergleichsweise hohen Taktfrequenzen zu nutzen. 
Entsprechend wurde uClinux als Abwandlung des Linux-Kerns für Systeme ohne 
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MMU entwickelt. Seit der Kernversion 2.5.45 ist uClinux integraler Bestandteil des 
regulären Linux-Kerns für verschiedene Prozessorarchitekturen wie ARM7TDMI, 
ARM Cortex-M3/4/7/R, MIPS, M68k/ColdFire sowie FPGA-basierte Prozessoren 
wie Altera Nios II, Xilinx MicroBlaze und Lattice Mico 32. 

Das Fehlen einer Speicherverwaltungseinheit in uClinux-basierten Systemen 
bringt eine Reihe von Nachteilen mit sich. Eine direkte Folge ist der fehlende 
Speicherschutz, somit kann jeder Prozess beliebig den Speicher anderer Prozes- 
se auslesen und beschreiben. Das Fehlen einer MMU hat aber auch Folgen fiir die 
Unix-eigene Methode zur Erzeugung neuer Prozesse. Normalerweise werden Pro- 
zesse in Unix als eine Kopie (Kindprozess) eines existierenden Prozesses durch 
den fork()-Systemaufruf erstellt [470]. Dieser erzeugt aus Effizienzgriinden keine 
komplette Kopie des Speicherinhalts des aufrufenden Prozesses, sondern repliziert 
nur dessen Seitentabelleneinträge, die im Kindprozess auf dieselben physikalischen 
Seitenrahmen zeigen wie im aufrufenden Elternprozess. Wenn nun der Kindprozess 
Daten in seinen Speicher schreibt, wodurch sich sein Speicherinhalt von dem des 
Elternprozesses unterscheidet, werden nur die davon betroffenen Seitenrahmen mit 
einer copy-on-write-Strategie kopiert. Die fehlende Unterstützung für die copy-on- 
write-Semantik in MMU-losen Systemen und der in Folge benötigte hohe Aufwand, 
bei Aufruf von fork() alle Seiten des Elternprozesses zu kopieren, führen dazu, 
dass fork() in uClinux nicht zur Verfügung steht. 

Stattdessen stellt uClinux den vfork ()-Systemaufruf zur Verfügung. Dieser Sys- 
temaufruf nutzt aus, dass die meisten Unix-Prozesse direkt nach ihrer Erzeugung den 
Systemaufruf exec() verwenden, um ihren Speicherinhalt durch den einer anderen 
ausführbaren Datei zu ersetzen: 


pid_t kindPID; 

kindPID = vfork(); 

if (kindPID == @) { // im Kindprozess 
exec("/bin/sh", "sh", ®); 


printf("Elternprozess läuft wieder, PID des Kindprozesses ist %d", kindPID); 


Der direkte Aufruf von exec() nach fork() bedingt, dass der Inhalt des gesam- 
ten Adressraums des neu erzeugten Prozesses auf jeden Fall ersetzt wird und nur 
der kleine Teil des Kindprozesses tatsächlich ausgeführt wird, der exec() aufruft. 
Verglichen mit dem Standardverhalten von Unix garantiert vfork, dass der Eltern- 
prozess nach dem Aufruf von fork so lange angehalten wird, bis der Kindprozess 
exec() aufgerufen hat. Dadurch ist der Elternprozess nicht dazu in der Lage, die 
Ausführung des Kindprozesses zu beeinflussen (z.B. durch Schreibvorgänge), bis 
dessen neuer Speicherinhalt geladen wurde. Zur sicheren Verwendung von vfork() 
müssen allerdings einige Einschränkungen beachtet werden. Es ist nicht erlaubt, 
den Stack des Kindprozesses zu verändern, d.h. vor exec dürfen keine Funktions- 
aufrufe erfolgen. Eine Folge davon ist, dass eine Rückkehr aus dem vfork-Aufruf 
im Falle eines Fehlers, z.B. bei zu geringem Speicher oder einem Fehler bei der 
Ausführung des neuen Programms, unmöglich ist, da dies den Stack verändern wür- 
de. Stattdessen lautet die Empfehlung, im Fehlerfall den Kindprozess mit Hilfe des 
exit()-Systemaufrufs zu beenden. 
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Zusammenfassend lässt sich feststellen, dass uClinux ein funktionierender An- 
satz ist, einen Teil der Linux-Funktionalität auf kleinen Mikrocontrollersystemen zu 
realisieren. Die auf dem Chip verfügbare Menge an RAM ist aber aktuell auch bei 
größeren Mikrocontrollern auf wenige hundert Kilobyte beschränkt. Eine minimale 
uClinux-Version benötigt aber rund 8 MB RAM und erfordert daher einen zusätzli- 
chen externen RAM-Baustein. Für Systeme mit geringem Hauptspeicher wird also 
auch in Zukunft ein traditionelles Echtzeitbetriebssystem eher das System der Wahl 
bleiben. 


4.4.6 Evaluation der Nutzung von Linux in eingebetteten Systemen 


Neben den technischen Kriterien bringt die Entscheidung, ob ein eingebettetes Sys- 
tem auf Linux basieren soll, auch rechtliche und wirtschaftliche Fragen mit sich. 

Auf der technischen Seite unterstützt Linux eine große Anzahl an Prozessorar- 
chitekturen, SoCs, Peripherieeinheiten und Kommunikationsprotokollen, die übli- 
cherweise bei eingebetteten Systemen zum Einsatz kommen, wie z.B. das Internet- 
Protokoll TCP/IP, CAN, Bluetooth® und IEEE802.15.4/ZigBee®. Linux stellt eine 
POSIX-ähnliche Programmierschnittstelle zur Verfügung, welche die Portierung von 
existierendem Code erleichtert. Dieser Code muss nicht notwendigerweise in C oder 
C++ geschrieben sein, sondern kann auch Skriptsprachen wie Python und Lua oder 
gar spezialisiertere Sprachen wie Erlang verwenden. Entwicklungswerkzeuge für 
Linux sind kostenfrei verfügbar und lassen sich einfach in existierende IDE-basierte 
Entwicklungsprozesse, z.B. mit Eclipse, und Dienste zur kontinuierlichen Integrati- 
on wie Jenkins integrieren. Im allgemeinen ist die Codebasis von Linux wohlerprobt, 
allerdings variiert die Qualität der Unterstützung je nach Plattform. Bei Verwendung 
einer weniger verbreiteten Hardwareplattform wird empfohlen, die Stabilität der Un- 
terstützung für den Prozessor und die Gerätetreiber sorgfältig zu prüfen. Ein Nachteil 
der Verwendung von Linux ist die Komplexität der großen Codebasis, die einen guten 
Einblick in und Erfahrung mit dem System erfordert, um Probleme finden und behe- 
ben zu können. Hier bieten aber verschiedene Halbleiterhersteller und Drittanbieter 
kommerzielle Unterstützung für eingebettetes Linux an, bis hin zur Verfügbarkeit 
kompletter grundlegender Systemportierungen, sogenannter board support software 
packages (BSPs), für verschiedene Referenzsysteme. 

Aus einem wirtschaftlichen Blickwinkel ist der offensichtliche Vorteil von Linux, 
dass der Quellcode kostenfrei zur Verfiigung steht. Der Linux-Kern unterliegt der 
GPL-Lizenz Version 2!%. Diese erfordert, dass der Quellcode für Modifikationen 
der existierenden Codebasis zusammen mit dem erzeugten Binärcode zur Verfü- 
gung gestellt werden muss. Dies kann dazu führen, dass Geschäftsgeheimnisse von 
Hardwarekomponenten offengelegt werden oder Vertraulichkeitsvereinbarungen mit 
den Anbietern von Hardwarekomponenten gebrochen werden. Für bestimmte Hard- 
ware, wie z.B. Grafikkartentreiber, wird dies umgangen, indem binäre Code-,,Blobs” 


19 Siehe http://www.gnu.org/licenses/gpl-2.0.html. 
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verwendet werden, die nur durch einen quelloffenen Lader zum Kern hinzugefügt 
werden. Dieser Ansatz wird aber von den Linux-Kernentwicklern abgelehnt. 

Ein zunehmend kritisches Problem ist die Sicherheit von Linux-basierten einge- 
betteten Systemen, besonders im Internet der Dinge. Viele den Linux-Kern betref- 
fende Sicherheitslücken finden sich auch in eingebettetem Linux. Kostengünstige 
Verbrauchergeräte, wie Internet-basierte Kameras, Router und Mobiltelefone, erhal- 
ten nur in Ausnahmefällen Softwareaktualisierungen, sind aber oft viele Jahre im 
Einsatz. Dadurch sind diese Geräte Sicherheitslücken ausgesetzt, die bereits aktiv 
ausgenutzt werden, z.B. für massive verteilte Angriffe auf die Verfügbarkeit von 
Servern (sogenannte denial-of-service-Angriffe (DDOS)), die von Tausenden von 
kompromittierten Linux-Geräten ausgehen. Entsprechend müssen für einen sicheren 
Betrieb von Linux-basierten Systemen die Kosten für eine kontinuierliche Aktuali- 
sierung der Software sowohl für in Produktion befindliche wie auch ausgelaufene, 
aber noch aktiv betriebene Geräte, in der Kalkulation berücksichtigt werden. 


4.5 Hardware-Abstraktionsschicht 


Hardware-Abstraktionsschichten (engl. Hardware Abstraction Layers (HALs)) er- 
möglichen es, auf Hardware über eine Hardware-unabhängige Programmierschnitt- 
stelle (API) zuzugreifen. Wir könnten uns hier z.B. eine Hardware-unabhängige 
Methode zum Zugriff auf Zeitgeber vorstellen, die unabhängig von den jeweili- 
gen Adressen der Zeitgeber funktioniert. Hardware-Abstraktionsschichten kommen 
meist zwischen der Hardware und dem Betriebssystem zum Einsatz. Sie stellen 
Software Intellectual Property (IP) zur Verfügung, sind aber weder Teil des Be- 
triebssystems, noch können sie als Middleware angesehen werden. Ein Überblick 
über Arbeiten in diesem Bereich ist bei Ecker, Müller und Dömer [145] zu finden. 


4.6 Middleware 


Kommunikationsbibliotheken sind ein Mittel, um Sprachen, die keine entsprechen- 
den Eigenschaften besitzen, um Funktionalität zur Kommunikation zu erweitern. 
Sie stellen Kommunikationsfunktionalität auf Basis der grundlegenden Funktiona- 
lität des Betriebssystems zur Verfügung. Da sie auf dem Betriebssystem aufbauen, 
können sie Betriebssystem-unabhängig sein (und damit auch unabhängig von der 
verwendeten Prozessorhardware). Als Ergebnis entstehen damit vernetzte cyber- 
physikalische Systeme. Derartige Kommunikation wird auf für das Internet der 
Dinge benötigt. Ein Trend geht dahin, sowohl Kommunikation innerhalb eines loka- 
len Systems wie auch Kommunikation über weitere Entfernungen zu unterstützen. 
Auch hier nimmt die Verwendung von Internetprotokollen weiter zu. Häufig erlauben 
solche Protokolle die sichere Kommunikation auf der Basis von Ver- und Entschlüs- 
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selung (siehe Seite 214). Die entsprechenden Algorithmen sind eine spezielle Klasse 
von Middleware. 


4.6.1 OSEK/VDX COM 


OSEK/VDX® COM ist ein besonderer Kommunikationsstandard fiir das OSEK- 
Betriebssystem [441]?° aus dem Automobilbereich. OSEK COM stellt eine ,,Inter- 
aktionsschicht” als Programmierschnittstelle zur Verfügung, über die sowohl interne 
Kommunikation (Kommunikation innerhalb eines Steuergerätes) wie auch exter- 
ne Kommunikation (Kommunikation mit anderen Steuergeräten) realisiert werden 
kann. OSEK COM spezifiziert dabei nur die Funktionalität der Interaktionsschicht. 
Entsprechende Implementierungen müssen eigenständig entwickelt werden. 

Die Interaktionsschicht kommuniziert mit anderen Steuergeräten über eine ,,Netz- 
werkschicht” und eine „Data Link”-Schicht. Einige der Anforderungen an diese 
Schichten werden von OSEK COM definiert, aber diese Schichten sind nicht Teil 
von OSEK COM selbst. Auf diese Weise kann Kommunikation auf Basis verschie- 
dener Netzwerkprotokolle realisiert werden. 

OSEK COM ist ein Beispiel für Kommunikations-Middleware, die für eingebette- 
te Systeme bestimmt ist. Ausser diesen speziell für eingebettete Systeme entwickelten 
Middleware-Systemen können auch viele für nicht eingebettete Systeme entwickelte 
Kommunikationsstandards für eingebettete Systeme angepasst werden 


4.6.2 CORBA 


CORBA® (Common Object Request Broker Architecture) [433] ist ein Beispiel eines 
solchen angepassten Standards. CORBA ermöglicht den Zugriff auf entfernte Diens- 
te, auf entfernte Objekte kann über standardisierte Schnittstellen zugegriffen werden. 
Klienten kommunizieren in CORBA mit lokalen Hilfsfunktionen (engl. stubs), die 
den Zugriff auf entfernte Objekte vortäuschen. Die Klienten senden Informationen 
über das gewünschte Objekt sowie eventuelle Parameter an den Object Request Bro- 
ker (ORB, siehe Abb. 4.18). Der ORB ermittelt darauf den Ort des Objektes, auf das 
zugegriffen werden soll, und sendet die Information über ein standardisiertes Proto- 
koll, wie z.B. IIOP, an den Ort, an dem sich das Objekt befindet. Diese Information 
wird dann über ein Skeleton an das eigentliche Objekt weitergeleitet und die vom 
Objekt angeforderte Information wird gegebenenfalls wieder über den ORB zurück 
zum Klienten übertragen. 

Der CORBA-Standard verfügt nicht über die für Echtzeitanwendungen notwen- 
dige Vorhersagbarkeit. Daher wurde ein spezieller Echtzeit-CORBA-Standard (RT- 
CORBA) definiert [429]. Eine sehr wichtige Eigenschaft von RT-CORBA ist es, 


20 OSEK ist ein Warenzeichen der Continental Automotive GmbH. 
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Klient „Objekt 
Stub Skeleton 
IIOP-Protokoll 
ORB1 ORB2 


Abb. 4.18 Zugriff auf entfernte Objekte mit CORBA 


Ende-zu-Ende-Vorhersagbarkeit von Piinktlichkeit in einem System mit festen 
Prioritaten zur Verfiigung zu stellen. Dies beinhaltet das Respektieren von Thread- 
Prioritäten zwischen Klient und Server, um Ressourcen-Wettstreit-Situationen 
aufzulösen und ein Begrenzen der Latenzen von Operationsaufrufen. Ein besonderes 
Problem von Echtzeitsystemen ist es, dass Thread-Prioritäten möglicherweise nicht 
beachtet werden, wenn Threads exklusiven Zugriff auf Ressourcen erhalten. Das Pro- 
blem der Prioritätsumkehr (siehe Seite 231) muss in RT-CORBA behandelt werden. 
RT-CORBA beinhaltet Vorkehrungen, um die Zeit zu begrenzen, innerhalb derer 
eine solche Prioritätsumkehr vorkommen kann. RT-CORBA verfügt zudem über 
Methoden, um Thread-Prioritäten zu verwalten. Diese Priorität ist unabhängig von 
den Prioritäten des unterliegenden Betriebssystems, auch wenn sie mit den Echtzeit- 
Erweiterungen des POSIX-Standards kompatibel ist [202]. Die Thread-Priorität von 
Klienten kann auf die Server-Seite übertragen werden. Prioritätsverwaltung ist auch 
für Funktionen verfügbar, die gegenseitigen Ausschluss beim Zugriff auf Ressourcen 
zur Verfügung stellen. Das ab Seite 233 beschriebene Prioritätsvererbungsprotokoll 
muss in RT-CORBA-Implementierungen zur Verfügung stehen. Eine Menge an be- 
reits existierenden Threads reduziert dabei den Aufwand für die Thread-Erzeugung 
und Instanziierung. 


4.6.3 POSIX Threads (Pthreads) 


Die POSIX Thread-Bibliothek (Pthreads) ist eine Programmierschnittstelle (APD für 
Threads auf Betriebssystemebene [36]. Pthreads entsprechen dem Betriebssystem- 
standard IEEE POSIX 1003. 1c. Eine Menge von Threads kann im selben Adressraum 
ablaufen, damit kann Kommunikation über gemeinsam genutzten Speicher stattfin- 
den. Dies vermeidet die Speicherkopieroperationen, die MPI (siehe Unterabschnitt 
2.8.3) normalerweise mit sich bringt. Die Prhreads-Bibliothek eignet sich daher zur 
Programmierung von Mehrkern-Prozessoren, die sich einen Adressraum teilen. Die 
Bibliothek beinhaltet eine Standard-API mit Mechanismen für den gegenseitigen 
Ausschluss. Pthreads verwenden vollständig explizite Synchronisation [553]. Die 
genaue Semantik hängt dabei vom verwendeten Speicherkonsistenzmodell ab. Es 
ist schwierig, Synchronisation korrekt zu implementieren. Die Bibliothek kann als 
Grundlage zur Implementierung anderer Programmiermodelle verwendet werden. 
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4.6.4 UPnP und DPWS 


Universal Plug-and-Play (UPnP) ist eine Erweiterung des Plug-and-Play-Konzeptes 
von PCs auf über einem Netzwerk verbundene Geräte. Als Hauptziel wird die An- 
bindung von Netzwerkdruckern, Speichergeräten und Routern in Heim- und Bü- 
ronetzwerken gesehen [438]. Aus Sicherheitsgründen werden hierbei nur Daten 
ausgetauscht, Code kann nicht übertragen werden. 

Das Devices Profile for Web Services (DPWS) zielt auf eine allgemeinere Ver- 
wendbarkeit als UPnP. „Das Devices Profile for Web Services (DPWS) definiert eine 
minimale Menge von Implementierungsbeschränkungen, um sicheres Versenden von 
Nachrichten zu Web Services, deren Auffinden, Beschreibung und Ereignisbehand- 
lung auf ressourcenbeschränkten Geräten zu ermöglichen” [597]. DPWS spezifiziert 
Dienste zum Auffinden von an einem Netzwerk angebundenen Geräten, zum Aus- 
tausch von Informationen über verfügbare Dienste und zum Veröffentlichen und 
Abonnieren (Stichwort: publish and subscribe) von Ereignissen. 

In Ergänzung der für Hochleistungsrechnen entworfenen Bibliotheken können 
einige generische Netzwerk-Kommunikationsbibliotheken eingesetzt werden. Diese 
wurden meist für eine lose Kopplung über Internet-basierte Kommunikationsproto- 
kolle entworfen. 

MPI (siehe Seite 125), OpenMP (siehe Seite 126), OSEK/VDX COM, CORBA, 
Pthreads, UPnP und DPWS sind Spezialfälle von Kommunikations-Middleware 
(Software, die in einer Schicht zwischen Betriebssystem und Anwendungen genutzt 
wird). Ursprünglich wurden sie für die Kommunikation zwischen PCs entwickelt 
(mit Ausnahme von OSEK/VDX COM). Es gibt jedoch Versuche, die gewonnenen 
Erkenntnisse und entwickelten Techniken auch für eingebettete Systeme nutzbar zu 
machen. 

Dieser Ansatz könnte besonders für mobile Geräte wie Smartphones geeignet 
sein. Für „harte” Echtzeitsysteme mögen der notwendige Aufwand, ihre Echtzeitfä- 
higkeiten und ihre Dienste unpassend sein. 


4.7 Echtzeitdatenbanken 


Datenbanken bieten eine bequeme und strukturierte Art, Informationen zu spei- 
chern und auf sie zuzugreifen. Dementsprechend besitzen Datenbanken eine API 
zum Schreiben und Lesen von Informationen. Eine Folge von Lese- und Schreib- 
operationen wird eine Transaktion genannt. Transaktionen können aus einem der 
folgenden Gründe abgebrochen werden: es könnten Hardwareprobleme, Verklem- 
mungen, Probleme mit der Kontrolle der Nebenläufigkeit usw. auftreten. Eine übliche 
Anforderung ist, dass Transaktionen den Zustand der Datenbank nicht verändern, 
bis sie erfolgreich zu Ende gelaufen sind. Daher werden durch Transaktionen ange- 
forderte Änderungen meist nicht realisiert, bis sie committed werden. Die meisten 
Transaktionen müssen dabei atomar sein. Dies bedeutet, dass das Endergebnis (der 
neue Zustand der Datenbank), das durch eine Transaktion erzeugt wurde, entweder 
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der Zustand ist, der durch vollständiges Abarbeiten der Transaktion entsteht oder 
aber der vorherige Zustand. Zudem muss der Zustand der Datenbank, der aus ei- 
ner Transaktion resultiert, konsistent sein. Die Konsistenzanforderungen beinhalten 
z.B., dass Ergebnisse von Leseanforderungen derselben Transaktion konsistent sind 
(also keinen Zustand beschreiben, der niemals in der von der Datenbank modellierten 
Umgebung existiert hat). Weiterhin soll für einen anderen Benutzer der Datenbank 
kein Zwischenzustand, der aus einer partiellen Ausführung einer Transaktion ent- 
steht, sichtbar sein (die Transaktionen müssen durchgeführt werden, als ob sie in 
Isolation stattfinden würden). Schließlich müssen die Ergebnisse der Transaktionen 
persistent sein. Diese Eigenschaft wird auch als Dauerhaftigkeit der Transaktionen 
bezeichnet. Zusammengenommen bilden die vier fett gedruckten Eigenschaften die 
ACID-Eigenschafen (siehe das Buch von Krishna and Shin [311], Kapitel 5). 

Einige Datenbanken erfordern weiche Echtzeitbedingungen. So sind zum Bei- 
spiel die Zeitanforderungen für Flugreservierungssysteme weich. Im Gegensatz dazu 
kann es auch harte Beschränkungen geben. So muss beispielsweise die automatische 
Erkennung von Fußgängern in automobilen Anwendungen und die Zielerkennung 
in militärischen Anwendungen harten Echtzeitbedingungen genügen. Die obigen 
Anforderungen erschweren das Einhalten von Echtzeitbedingungen. Beispielswei- 
se könnten Transaktionen mehrfach abgebrochen worden sein, bevor sie endgültig 
committed werden. Bei allen Datenbanken, die virtuellen Speicher und Festplatten 
zu Grunde legen, sind die Zugriffszeiten auf die Platten kaum vorhersagbar. Mögli- 
che Lösungen liegen hier bei Hauptspeicherdatenbanken und der Verwendung von 
Flash-Speichern. Eingebettete Datenbanken sind oft klein genug, um solche Ansätze 
zu realisieren. In anderen Fällen kann es möglich sein, die ACID-Anforderungen zu 
lockern. Weitere Informationen hierzu finden sich im Buch von Krishna und Shin 
sowie auch bei Lam und Kuo [320]. 


4.8 Aufgaben 


Die folgenden Aufgaben sollten entweder zu Hause oder während einer Anwesen- 
heitsphase nach dem flipped classroom-Konzept [376] bearbeitet werden: 


4.1: Mit welchen Methoden kann man ein Betriebssystem an die Anforderungen 
in einem konkreten Produkt so anpassen, dass alle Ressourcen möglichst effizient 
genutzt werden? 


4.2: Welche Anforderungen muss ein Echtzeitbetriebssystem erfüllen? Wie unter- 
scheiden sie sich von den Anforderungen an ein Standard-Betriebssystem? Welche 
Eigenschaften eines Standard-Betriebssystems wie Windows oder Linux könnten 
vielleicht in einem Echtzeitbetriebssystem fehlen? 


4.3: Wie viele Sekunden wurden in der Silvesternacht insgesamt hinzugefügt, um 
den Unterschied zwischen UTC und TAI seit 1958 zu kompensieren? Suchen Sie im 
Internet nach einer Lösung für diese Aufgabe! 
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4.4: Finden Sie Prozessoren, die über eine Speicherschutzeinheit (engl. Memory 
Protection Unit (MPU)) verfügen! Wie unterscheiden sich MPUs von den häufiger 
anzutreffenden Memory Management Units (MMUs, siehe Anhang C)? Suchen Sie 
im Internet nach einer Lösung für diese Aufgabe! 


4.5: Beschreiben Sie Klassen von eingebetteten Systemen, für die Schutz auf jeden 
Fall verfügbar sein sollte! Beschreiben Sie auch Klassen von eingebetteten Systemen, 
für die Schutz möglicherweise nicht notwendig ist! 


4.6: Entwickeln Sie ein Beispiel, das die Prioritätsumkehr für ein System mit drei 
Tasks demonstriert! 


4.7: Laden Sie das levi-Modul leviRTS von der levi-Webseite [497]. Modellieren Sie 
eine Jobmenge wie in Tabelle 4.1 dargestellt. 


Tabelle 4.1 Jobmenge mit exklusiven Ressourcenanforderungen 


Job | Priorität |Ankunft|Laufzeit | Kamera | Mikrofon 


tp,Pp |iv,P |Ip,c |tv,c 
Jı | 1 (hoch) 3 4 1 4 = - 
Jy 2 10 3 - - 1 2 
J3 3 5 6 - - 4 6 
J4 |4 (niedrig) 0 7 2 5 - - 


tp,p und tp c sind die Zeitpunkte relativ zur Startzeit, zu denen ein Job die 
exklusive Benutzung der Kamera bzw. des Mikrofons anfordert (ArP in levi). tv,p 
und tyc sind die Zeitpunkte relativ zur Startzeit, zu denen diese Ressourcen wieder 
freigegeben werden. Verwenden Sie prioritätsbasiertes, präemptives Scheduling! 
Welches Problem tritt hier auf? Wie kann es gelöst werden? 


4.8: Welche Protokolle zum exklusiven Zugriff auf Ressourcen verhindern Dead- 
locks? 


4.9: Wie wird in ERIKA die Benutzung des Stacks optimiert? 


4.10: Welche Probleme müssen gelöst werden, wenn Linux als Betriebssystem für 
eingebettete Systeme benutzt wird? 


4.11: Welchen Einfluss hat das Prioritätsumkehr-Problem auf den Entwurf von 
Netzwerk-Middleware? 


4.12: Welchen Einfluss könnte Flash-Speicher auf den Entwurf von Echtzeitdaten- 
banken haben? 
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Kapitel 5 mM 
Bewertung und Validierung “pate 


Während des Entwurfs müssen wir uns immer wieder davon überzeugen, dass das 
geplante System voraussichtlich seine Funktion erfüllen wird und gemäß aller rele- 
vanten Bewertungskriterien die Anforderungen einhalten wird. Diesem Zweck die- 
nen die Validierung und die Bewertung von Zwischenzuständen im Entwurfsprozess. 
In den Abschnitten 5.1.2 bis 5.6 geben wir einen Überblick über wichtige Bewer- 
tungstechniken. Dabei werden Bewertungstechniken für eine Anzahl von Kriterien 
vorgestellt, insbesondere für die Kriterien der Ausführungszeit, der Ergebnisquali- 
tät, des Energieverbrauchs, des thermischen Verhaltens und der Verlässlichkeit. Wir 
betrachten in diesem Rahmen ausführlich Basistechniken zur Bestimmung der größt- 
möglichen Ausführungszeit. Wir empfehlen, auf der Basis der vorgestellten Modelle 
des Energieverbrauchs jeweils ein dem vorliegenden Problem angepasstes Energie- 
modell zu entwickeln. Das Problem der thermischen Modellierung führen wir auf 
das äquivalente Problem der Modellierung von elektrischen Schaltkreisen zurück. 
Zur Berechnung der Verlässlichkeit stellen wir Basistechniken der statistischen Ana- 
lyse der Zuverlässigkeit, die Fehlerbaumtechnik sowie die Fehlermöglichkeits- und 
Einflussanalyse vor. Zum Vergleich der Bewertungen gemäß verschiedener Kriteri- 
en stellen wir das Konzept der Pareto-Optimalität vor. Beginnend mit Abschnitt 5.7 
werden wir einen kurzen Überblick über Validierungstechniken (wie die Simulation, 
das Rapid Prototyping und die formale Verifikation) geben. 


5.1 Einleitung 


5.1.1 Begriffe 


Spezifikationen, Hardwareplattformen und Systemsoftware stellen die grundlegen- 
den Zutaten zur Verfügung, die für den Entwurf eingebetteter Systeme benötigt wer- 
den. Während des Entwurfsprozesses müssen Entwürfe bewertet (oder ,,evaluiert’”’) 
und validiert werden. Diese Entwurfsschritte können wie folgt definiert werden: 
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Definition 5.1: Bewertung oder Evaluation ist der Vorgang, quantitative Informa- 
tionen einiger wichtiger Kriterien (oder „Ziele”) eines bestimmten (möglicherweise 
partiellen) Entwurfs zu berechnen. 


Definition 5.2: Validierung ist die Überprüfung, ob ein bestimmter (Teil-)Entwurf 
für seinen Zweck geeignet ist, alle Bedingungen erfüllt und die geforderte Verarbei- 
tungsleistung erbringt. 


Definition 5.3: Validierung mit mathematischer Genauigkeit wird als (formale) Ve- 
rifikation bezeichnet. 


Bewertung und Validierung sind in verschiedenen Phasen des Entwurfsvorgangs 
erforderlich (siehe Abb. 5.1). Diese Aktionen und der Entwurf sollten verzahnt sein 
und nicht als voneinander unabhängige Aktivitäten betrachtet werden. Auch wenn 


N ee a N 
Spezifikation Entwurfsdatenbank Entwurf 
a \ J 
5 | 
Bec Abbildung von Test 
g 2 HW-Komponenten Anwendungen 
Cc .z 
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Bewertung & Validierung 
\ (RTOS, ...) 


Abb. 5.1 Kontext dieses Kapitels 


Bewertung und Validierung deutliche Unterschiede aufweisen, so sind sie dennoch 
eng miteinander verwandt. Der großen Bedeutung einer wiederholten Bewertung 
und Validierung wegen werden wir diese Vorgänge vor den eigentlichen Entwurfs- 
schritten beschreiben. 


5.1.2 Multikriterielle Optimierung 


Bewertungen von Entwürfen werden im Allgemeinen zu einer Charakterisierung des 
Entwurfs anhand mehrerer Kriterien führen, wie Ausführungszeit, Energieverbrauch, 
Ergebnisqualität, thermisches Verhalten und Verlässlichkeit. Es ist meist nicht rat- 
sam, alle diese Kriterien in einer einzelnen Zielfunktion (z.B. durch Verwendung 
eines gewichteten Mittelwerts) zusammenzufassen, da dies einige der wichtigen 
Eigenschaften des Entwurfs unterdrücken könnte. Es ist vielmehr ratsam, dem Ent- 
wickler eine Anzahl an Entwürfen vorzuschlagen, unter denen dieser den passenden 
Entwurf auswählen kann. Jedoch sollte diese Menge bereits ausschließlich „vernünf- 
tige” Entwürfe beinhalten. Das Finden solcher Mengen von Entwürfen ist der Zweck 
von multikriteriellen Optimierungstechniken. 
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Um multikriterielle Optimierungen durchzufiihren, betrachten wir einen m- 
dimensionalen Raum X möglicher Lösungen des Optimierungsproblems. Diese 
Dimensionen könnten beispielsweise die Anzahl der Prozessoren, die Größen von 
Speichern und die Art und Anzahl von Bussen darstellen. Auf diesem Raum X de- 
finieren wir eine n-dimensionale Funktion, die Entwürfe in Hinblick auf mehrere 
Kriterien oder Ziele (z.B. Kosten und Leistung) hin evaluiert: 


f(x) = (Aa. na) mit x € X 


Sei F der n-dimensionale Werteraum dieser Ziele (der sogenannte Zielraum). Fiir 
jedes der Ziele ist eine Ordnung < und die entsprechende <-Ordnung definiert. Im 
Folgenden nehmen wir an, dass wir die Minimierung der Ziele erreichen wollen. 


Definition 5.4: Ein Vektor u = (u,...,.u,) € F dominiert einen Vektor v = 
(vi, Vn) € F genau dann, wenn u in Hinblick auf mindestens ein Ziel „besser” als 
v und nicht schlechter als v für alle anderen Ziele ist: 


Vie {1,...n}: ui < vi A (5.1) 
Jj € {1,. n}: uj < vj (5.2) 


Definition 5.5: Ein Vektor u € F wird indifferent zu einem Vektor v € F genannt 
genau dann, wenn weder der Vektor u den Vektor v dominiert noch der Vektor v den 
Vektor u. 


Definition 5.6: Ein Entwurf x € X heißt Pareto-optimal auf X genau dann, wenn 
es keinen Entwurf y € X gibt, so dass u = f(x) von v = f(y) dominiert wird. 


Die vorstehende Definition definiert Pareto-Optimalität im Lösungsraum. Die fol- 
gende Definition liefert die Entsprechung für den Zielraum. 


Definition 5.7: Sei S < F eine Teilmenge von Vektoren im Zielraum. v € F ist 
eine nicht dominierte Lösung von S genau dann, wenn v von keinem Element € S 
dominiert wird. v heißt Pareto-optimal genau dann, wenn v nicht dominiert wird in 
Hinblick auf alle Lösungen F. 


Abb. 5.2 verdeutlicht die unterschiedlichen Gebiete in einem Zielraum mit den Opti- 
mierungskriterien O1 und O2 relativ zum Entwurfspunkt (1). Abb. 5.2 (links) zeigt 
Pareto-Punkte und die obere rechte Fläche beschreibt Entwürfe, die von Entwurf (1) 
dominiert werden, da diese „schlechter” in Hinblick auf beide Ziele sind. Entwürfe 
im linken unteren Rechteck (wenn sie existieren würden) würden den Entwurf (1) 
dominieren, da sie in Hinlick auf beide Ziele ,,besser” wären. Entwürfe in der linken 
oberen und rechten unteren Ecke sind indifferent: sie sind „besser” in Hinblick auf 
ein Ziel und „schlechter” in Hinblick auf das andere. Abb. 5.2 (rechts) zeigt eine 
Menge von Pareto-Punkten, mit + markiert. Dominierte Entwurfspunkte sind alle 
Punkte in diesem Diagramm, die von mindestens einem Pareto-Punkt dominiert 
sind. Sie ergeben sich also als Vereinigung aller von einem Pareto-Punkt dominier- 
ten Punkte. Die Pareto-Front grenzt diese Punkte vom übrigen Teil des Diagramms 
ab. Die Pareto-Front wird durch eine Treppenfunktion dargestellt. 
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O2 (z.B. Speicherplatz) O2 (z.B. Speicherplatz) 

a dominiert von (1) 

indifferent (schlechter) dominierte 
min A) Entwurfspunkte 

= er 
min 
| dominiert (1) 
(besser) indifferent | 
<«+— min 01 + min 01 
(z.B. Energie) (z.B. Energie) 


Abb. 5.2 Pareto-Optimalität: links: Pareto-Punkt; rechts: Pareto-Front 


Definition 5.8: Unter Entwurfsraumexploration auf der Basis der Pareto-Optimalität 
verstehen wir den Vorgang, Pareto-optimale Lösungen zu finden und dem Entwerfer 
zu präsentieren, sodass dieser die am besten geeignete Lösung auswählen kann. 


Zur Visualisierung der Bewertung anhand von Metriken in vielen Dimensionen 
können sogenannte Kiviat-, Spinnennetz- oder Radardiagramme benutzt werden 
[577]. Sie sind Erweiterungen der Abbildung 2.74 auf mehrere Dimensionen. 


Beispiel 5.1: Wir können mehrere Entwürfe (z.B. für ein Mobiltelefon) ähnlich der 
nachfolgend beschriebenen Kriterien zu vergleichen (siehe Abb. 5.3). 


Kosten durchschnittliche 


Antwortzeit 


Ausfallrate größtmögliche 
Antwortzeit 
Sicherheits- j 
anfälligkeiten 1/Display- 
auflösung 
Maximale , ; ; 
Temperatur 1/Batteriebetriebszeit 


Abb. 5.3 Kiviat-Diagramm für Spitzenmodell (rot), Mittelklasse (grün, gestrichelt) und Einstiegs- 
modell (blau) 


Einheitlich wird eine Minimierung angestrebt. Das Spitzenmodell erreicht gute 
Werte (außer bei den Kosten). Beim Einstiegsmodell ist es umgekehrt. V 
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5.1.3 Relevante Kriterien 


Für Server und PC-ähnliche Systeme spielt die erwartete durchschnittliche Verar- 
beitungsleistung die wichtigste Rolle beim Entwurf eines neuen Systems. Fiir einge- 
bettete und cyber-physikalische Systeme miissen mehrere Kriterien beriicksichtigt 
werden. Die folgende Liste erläutert, ob und wo ein bestimmtes Zielkriterium in 
diesem Buch diskutiert wird: 


1. Durchschnittliche Verarbeitungsleistung (Performanz): Information zu die- 
sem Kriterium gibt es im Abschnitt 5.2. Eine Bewertung nach diesem Kriterium 
erfolgt häufig auf der Basis von Simulationen, die im Abschnitt 5.7 behandelt 
werden. 

2. Größtmögliche Laufzeit/Echtzeitverhalten: Fundamentale Techniken zur Be- 
rechnung der größtmöglichen Laufzeit (engl. Worst Case Execution Time (WCET)) 
werden in Unterabschnitt 5.2.2 vorgestellt. Zusätzlich gibt es eine Einführung in 
den sogenannten Real-Time Calculus (RTC) im Unterabschnitt 5.2.3. 

3. Qualitätsmetriken: Metriken zur Bewertung der Qualität (der Ausgabe) von 
eingebetteten Systemen werden im Abschnitt 5.3 präsentiert. Qualitätsmetriken 
spielen auch eine Rolle bei der Bewertung der Transformation zwischen Zahlen- 
darstellungen, wie sie im Unterabschnitt 7.1.5 gezeigt werden. 

4. Energieverbrauch/elektrische Leistungsaufnahme: Ein Überblick über Tech- 
niken, um nach diesem Kriterium zu bewerten, wird im Abschnitt 5.4 gegeben. 

5. Thermisches Verhalten: Eine Einführung zu diesem Kriterium gibt es im Ab- 
schnitt 5.5. 

6. Verlässlichkeit: Verlässlichkeit (engl. dependability) ist das Thema des Ab- 
schnitts 5.6, mit Unterabschnitten zur Informations- und zur Betriebssicherheit. 

7. Elektromagnetische Verträglichkeit: Dieses Kriterium wird in diesem Buch 
nicht behandelt. 

8. Testbarkeit: Die Kosten, die zum Testen eines Systems aufgewendet werden 
müssen, können sehr hoch sein. In Einzelfällen übersteigen sie sogar die Produkti- 
onskosten. Daher sollte auch die Testbarkeit berücksichtigt werden, vorzugsweise 
bereits während des Entwurfs. Testbarkeit wird im Kapitel 8 behandelt.. 

9. Kosten: Kosten in Form von Chipfläche oder Geld werden in diesem Buch nicht 
weiter betrachtet. 

10. Gewicht, Robustheit, Verwendbarkeit, Erweiterbarkeit, Umweltfreundlich- 
keit, rechtliche Fragen: Auch diese Kriterien werden hier nicht weiter betrachtet. 


Es gibt auch noch weitere Bewertungskriterien. Beispielsweise können wir gemäß 
der Qualitätsstandards ISO/IEC 25022 [259], ISO/IEC 25023 [260] und ISO/EIC 
25024 [258] bewerten. Wir starten mit einer Betrachtung des Kriteriums ,,Verarbei- 
tungsleistung” (Performanz). Dabei wird der Schwerpunkt auf die Performanz im 
schlimmstmöglichen Fall gelegt. 
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5.2 Performanzbewertung 


Die Bewertung der Performanz hat zum Ziel, die Rechenleistung von Syste- 
men vorherzusagen. Dies ist eine große Herausforderung (insbesondere fiir cyber- 
physikalische Systeme), da wir Informationen über den worst case anstelle von 
Informationen über den durchschnittlichen Fall benötigen könnten. Diese Informa- 
tionen sind notwendig, um die Einhaltung von Echtzeitbedingungen garantieren zu 
können. 


5.2.1 Frühe Phasen 


Zwei unterschiedliche Arten von Techniken wurden vorgeschlagen, um bereits in 
frühen Entwurfsphasen Bewertungen der Performanz zu erhalten: 


e Geschätzte Kosten- und Performanzwerte: Eine ganze Reihe von Schätzern 
wurde für diesen Zweck entwickelt. Beispiele sind Arbeiten von Jha and Dutt 
[275] für Hardware und von Jain et al. [267] und Franke [167] für Software. Die 
Erzeugung ausreichend genauer Abschätzungen erfordert einen beträchtlichen 
Aufwand. 

e Genaue Kosten- und Performanzwerte: Wir können auch echten Software- 
Code (in Form einer Binärdatei) auf einer Hardwareplattform, die mit der zu 
entwickelnden eng verwandt ist, verwenden. Dies erfordert die aufwändige Be- 
reitstellung eines Modells der Hardwareplattform wie auch eine rasche Abbildung 
der Software auf diese. Dies ist nur möglich, wenn Schnittstellen zu „Software- 
Synthesewerkzeugen” (Compiler) und Hardware-Synthesewerkzeugen existieren. 
Diese Methode kann präzisere Ergebnisse als die Abschätzung liefern, kann da- 
bei aber auch erheblich mehr (und manchmal untragbar viel) Zeit in Anspruch 
nehmen. 


Um ausreichend präzise Informationen zu erhalten, muss auch die Kommunikation 
betrachtet werden. Unglücklicherweise ist es meist schwierig, die Kommunikations- 
kosten schon in frühen Entwurfsphasen zu berechnen. 

Formale Techniken zur Performanzbewertung wurden bereits von vielen For- 
schern veröffentlicht. Für eingebettete Systeme sind die Arbeiten von Thiele et 
al., Henia und Ernst et al. und Wilhelm et al. besonders relevant (siehe z.B. 
[536, 211, 587]). Diese Techniken setzen einen bestimmten Grad von Wissen über 
Architekturen voraus. Sie sind für frühe Entwurfsphasen weniger wichtig, einige 
von ihnen lassen sich aber auch anwenden, ohne alle Details der Zielarchitektur zu 
kennen. Alle diese Ansätze modellieren echte, physikalische Zeit. 
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5.2.2 Größtmögliche Ausführungszeiten 


Die Ablaufplanung oder das Scheduling von Tasks erfordert Wissen über deren Aus- 
führungsdauer, insbesondere wenn das Einhalten von Zeitbedingungen garantiert 
werden muss, wie etwa in Echtzeitsystemen. Die größtmögliche Ausführungszeit 
(engl. Worst Case Execution Time (WCET)) ist die Ausgangsbasis der meisten Sche- 
duling-Algorithmen. Einige im Zusammenhang mit der größtmöglichen Ausfüh- 
rungszeit wichtige Definitionen sind in Abb. 5.4 und der nachfolgenden Definition 
aufgeführt. 


Abb. 5.4 Begriffe im Zusam- Verteilung von Laufzeiten 
menhang mit der größtmöglichen 
Ausführungszeit 
BCET Er WCET 
1 | | t 
| | | 


Definition 5.9: Die größtmögliche Ausführungszeit (engl. Worst Case Execution 
Time (WCET)) ist das Maximum über alle Ausführungszeiten, die ein Programm be- 
nötigen kann, wenn beliebige Eingaben und ein beliebiger Anfangszustand möglich 
sind. 


Leider ist die WCET nur sehr schwer berechenbar. Allgemein ist es sogar unent- 
scheidbar, ob die WCET endlich ist oder nicht. Dies ist eine direkte Folge davon, 
dass es nicht entscheidbar ist, ob ein Programm terminiert oder nicht. Daher lässt sich 
die WCET nur für bestimmte Programme oder Tasks berechnen. Beispielsweise kann 
die WCET für Programme berechnet werden, die weder Rekursion noch Schleifen 
mit einer unbekannten Anzahl an Wiederholungen enthalten. Doch auch die Anwen- 
dung solcher Einschränkungen macht es meist in der Praxis unmöglich, die WCET zu 
berechnen. Die Auswirkungen der Fließbänder (engl. pipelines) von modernen Pro- 
zessorarchitekturen, die verschiedene Arten von Hazards (Risiken) erzeugen können 
und Speicherhierarchien mit begrenzter Vorhersagbarkeit von Trefferraten sind nur 
schwer während des Entwurfs vorhersagbar. Die Berechnung der WCET für Systeme 
mit Caches, Verdrängungen von Prozessen, Unterbrechungen und virtuellem Spei- 
cher ist eine noch größere Herausforderung. Daher müssen wir uns damit zufrieden 
geben, eine gute obere Schranke für die WCET angeben zu können. 

Solche oberen Schranken werden als geschätzte WCETs (engl. Estimated 
WCETs) oder WCET gsr bezeichnet. Diese Schranken sollten zumindest diese bei- 
den Eigenschaften besitzen: 


1. die Schranken sollten sicher sein (WCETgsr > WCET) und 
2. die Schranken sollten gut sein (WCETgsr-WCET « WCET). 
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Trotz der Verwendung des Begriffs „geschätzte“ handelt es sich um sichere Schran- 
ken. 

In einigen Fällen werden Architektureigenschaften, welche die durchschnittliche 
Ausführungszeit senken, aber nicht garantieren können, dass auch die WCET sinkt, 
in Echtzeitsystemen nicht weiter berücksichtigt (siehe Seite 169). Die Berechnung 
guter oberer Grenzen für die Ausführungszeit kann aber dennoch schwierig sein. 
Die oben beschriebenen Architektureigenschaften stellen auch ein Problem für die 
Berechnung der WCETzsr dar. Für Mehrkern-Systeme ist die Berechnung guter 
oberer Schranken noch schwieriger als für einzelne Kerne, da die zeitlichen Be- 
einflussungen häufig schwierig zu modellieren sind. Tatsächlich kann es mögliche 
Ressourcenkonflikte geben, die zur Folge haben, dass Mehrkern-Systeme größere 
Schranken haben als Einkern-Systeme. 


Definition 5.10: Die kleinstmögliche Ausführungszeit (engl. Best Case Execution 
Time (BCET)) eines Programms ist die kürzeste Ausführungszeit, die unter allen 
möglichen Eingaben und Anfangszuständen möglich ist. BCET gsr ist eine sichere 
und gute untere Schranke für die Ausführungszeit. 


Die Berechnung guter Grenzen für ein in einer Hochsprache wie C geschriebenes 
Programm ist ohne Kenntnis des erzeugten Assemblercodes und der verwendeten 
Architektur nicht möglich. Daher muss eine sichere Analyse den Maschinencode 
betrachten. Alle anderen Ansätze würden zu unsicheren Ergebnissen führen. 

Im Folgenden befassen wir uns im Detail mit der Abschätzung der WCET. Die- 
se Darstellung basiert auf der Beschreibung des Werkzeugs aiT von R. Wilhelm 
[587]. Die Architektur von aiT ist in Abb. 5.5 dargestellt. Unseren Erkenntnissen 
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Abb. 5.5 Architektur des Timinganalyse-Werkzeugs aiT 
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zu Problemen der Analysierbarkeit von Hochsprachen-Code folgend, fiihrt aiT die 
Analyse auf einer ausführbaren Binärdatei des zu analysierenden Codes durch. Aus 
diesem Code wird ein Kontrollflussgraph (engl. Control Flow Graph (CFG)) erzeugt. 
Daraufhin werden Schleifentransformationen angewandt. Diese umfassen Transfor- 
mationen zwischen Scheifen und rekursiven Funktionsaufrufen sowie das virtuelle 
„Abrollen” von Schleifen (engl. Joop unrolling). Dieses Abrollen ist „virtuell”, da 
es nur intern stattfindet, ohne tatsächlich den ausführbaren Code zu verändern. Die 
Ergebnisse werden im CRL-Format (engl. Control flow Representation Language) 
dargestellt. Die nächste Phase setzt nun statische Analysen ein. Statische Analysen 
lesen eine AIP-Datei mit Annotationen (Anmerkungen) des Entwicklers ein. Diese 
Annotationen beschreiben schwer oder unmöglich automatisch aus der Programm- 
struktur zu ersehende Information (z.B. Schranken für komplexe Schleifen). Die 
statischen Analysen bestehen aus Werte-, Cache- und Fließbandanalysen. 

Eine Werteanalyse berechnet maximale Intervalle für Werte in Registern und 
lokalen Variablen. Diese Angaben können für die Kontrollflussanalyse und die Da- 
tencacheanalyse verwendet werden. Häufig sind Werte wie Adressen genau bekannt 
(besonders für „sauberen” Code). Dies erleichtert die Vorhersage von Speicherzu- 
griffen sehr. 

Die nächsten Schritte sind die Cache- und die Fließbandanalyse. Nachfolgend 
beschreiben wir einige Details der Cacheanalyse. Wir gehen von einem n-fach men- 
genassoziativen Cache aus (siehe Abb. 5.6)!. Betrachten wir nun einen Teil (eine 
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innerhalb des Teilcaches 
/ 


— u 
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Tag Index Offset 


Abb. 5.6 n-fach mengenassoziativer Cache mit n=4 


Zeile) des Caches mit einem bestimmten Index (in Abb. 5.6 fett und blau dargestellt). 
Wir nehmen an, dass die Verdrängung aus dem Cache mittels der Least Recently 
Used (LRU)-Strategie erfolgt. Damit werden fiir alle Zugriffe auf einen bestimm- 
ten Index die n Speicherblöcke, auf die zuletzt zugegriffen wurde, in diesem Teil 
des Caches gespeichert. Dabei soll die erforderliche LRU-Verwaltungshardware für 


1 Wir setzen voraus, dass der Leser mit dem Konzept von Caches vertraut ist. 
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jeden Index verfügbar sein, wobei alle Indizes unabhängig voneinander behandelt 
werden. Unter dieser Annahme sind alle Verdrängungen für einen bestimmten Index 
vollständig unabhängig von den Entscheidungen für andere Indizes. Diese Unabhän- 
gigkeit ist sehr wichtig, da sie es uns ermöglicht, jeden der Indizes für sich alleine 
zu betrachten. 

Dementsprechend sehen wir uns nun das Verhalten des Caches für einen bestimm- 
ten Index und die dazu gehörige Cachezeile an. Was passiert jetzt bei einem Zugriff 
auf diesen Index? Als erstes betrachten wir den Fall des Zugriffs auf eine Variable 
e, die sich im Cache befindet. Nach dem Zugriff ist diese Variable die jüngste (siehe 
Abb. 5.7). In der Abbildung sind die Einträge links stets jünger als solche rechts. 


a | | ff} | fe} | > | fe} | fab | td} | ff 


Abb. 5.7 Zugriff auf Variable e macht sie zur jüngsten 


Im zweiten Fall gehen wir davon aus, dass wir einen Zugriff auf eine Variable c 
haben, die sich noch nicht im Cache befindet. In diesem Fall wird die älteste Variable 
verdrängt (siehe Abb. 5.8). 


{e} | {a} | td} | ff} > |{c} | fe} | fa} | {d} 


Abb. 5.8 Zugriff auf Variable c verdrängt f 


Als nächstes beschäftigen wir uns mit rekonvergenten Programmpfaden, wie sie 
nach der Bearbeitung von bedingten Anweisungen auftreten. Welche Informationen 
haben wir tiber den Inhalt des Cacheteils nach einer solchen Vereinigung? 

Wir miissen zwischen der may-Analyse und der must-Analyse unterscheiden. 
Die must-Analyse gibt Auskunft darüber, welche Informationen sich sicher im Cache 
befinden. Sie ist geeignet, Zusicherungen bei der Bestimmung von WCET-Schranken 
zu geben. Die may-Analyse resultiert in Aussagen darüber, welche Informationen 
sich möglicherweise im Cache befinden könnten. Diese Aussagen sind wichtig, um 
zu wissen, was sich mit Sicherheit nicht im Cache befindet. Mit diesem Wissen 
können wir BCET-Schranken bestimmen. 

Betrachten wir zunächst die must-Analyse für rekonvergente Programmpfade. 
Abbildung 5.9 zeigt eine entsprechende Situation. Das Alter der Einträge wachse 
innerhalb eines Rechtecks von links nach rechts. Das Speicherobjekt c in Abb. 5.9 
sei das jüngste Element in der Cachezeile, sofern wir über einen Programmpfad zur 
Rekonvergenz gelangen und a sei das jüngste Element, sofern wir über den anderen 
Pfad dorthin gelangen. Entsprechendes gilt für die älteren Einträge im Cache. Wir 
wollen jetzt im Kontext der must-Analyse bestimmen, was der „schlechteste“ Fall 
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Durchschnitt+maximales Alter 


{c} | fe} | {a} | {d} 


RR 
{} {} {a,c} | {d} 
a 


{a} |0 | {c.f} | td} 


Abb. 5.9 Must-Analyse fiir LRU-Caches bei rekonvergenten Pfaden 


nach der Rekonvergenz ist. Offensichtlich können wir nach der Rekonvergenz im 
Cache mit Sicherheit nur solche Speicherobjekte finden, die sich in der Schnittmenge 
der beiden urspriinglichen Cacheinhalte befanden. Als Alter miissen wir im Sinne 
der worst case-Analyse das maximale Alter annehmen. Abb. 5.9 zeigt das Ergebnis. 
Offensichtlich muss die Analyse fiir jeden Platz (jede Spalte) im Cache mit Mengen 
möglicher Einträge arbeiten. 

Betrachten wir nun die may-Analyse für rekonvergente Programmpfade. Abb. 
5.10 zeigt wiederum die Situation. Im resultierenden Cache können nunmehr offen- 


Vereinigung+minimales Alter 


{c} | fe} | {a} | td} 


{a,c} | {ef | } | {9} 


a 
Be 


{a} | {ef} | [td 


Abb. 5.10 May-Analyse fiir LRU-Caches bei rekonvergenten Pfaden 


sichtlich Speicherobjekte vorhanden sein, die vor der Rekonvergenz in einem der 
beiden Programmpfade vorhanden waren. Also miissen wir die Vereinigung der 
Speicherobjekte betrachten. Im bestmöglichen Fall müssen wir von dem jüngsten 
Alter der Speicherobjekte ausgehen. Abb. 5.10 zeigt das Ergebnis. 

Zu den statischen Analysen zählen auch Fließbandanalysen. Eine Fließband- 
analyse muss sichere Schranken für die Anzahl an Zyklen berechnen, die für die 
Ausführung des Maschinencodes, der sich im Fließband des Prozessors befindet, 
benötigt wird. Details der Fließbandanalyse werden von Hahn et al. [197] sowie S. 
Thesing [534] beschrieben. Das Endergebnis statischer Analysen enthält Schranken 
für die Ausführungszeiten für jeden Basisblock eines Programms. Die Ergebnisse 
werden in einer PER-Datei abgelegt, wie in Abb. 5.5 zu sehen. 

Die folgende Phase von aiT verwendet diese Schranken, um größtmögliche Aus- 
führungszeiten für das gesamte Programm zu ermitteln. Dieser Schritt basiert auf 
einem Modell der Ganzzahligen Linearen Programmierung (engl. integer linear 
programming (ILP), siehe Anhang A). Dementsprechend enthält das Modell der 
Ausführungszeiten zwei Typen von Information: 
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e Die Zielfunktion: in unserer Anwendung der ILP-Modellierung nutzen wir die 
Gesamt-Ausfiihrungszeit als Zielfunktion, die zu maximieren ist. Diese Zeit wird 
als Summe der Ausführungszeiten der Basisblöcke bestimmt: 


WCETeEsr = > ej * fi (5.3) 
Basisblöcke 


wobei e; die größtmögliche Ausführungszeit von Basisblock i ist (die in der stati- 
schen Analyse berechnet wird) und f; ist dessen Ausführungshäufigkeit. Die Aus- 
führungshäufigkeiten können möglicherweise nicht alle vollständig automatisch 
bestimmt werden. Daher werden Zusatzinformationen des Entwerfers benötigt, 
wie z.B. Schleifengrenzen. 

e Lineare Randbedingungen: in unserer Anwendung der ILP-Modellierung nut- 
zen wir lineare Randbedingungen, um die Struktur des Datenflussgraphen zu 
repräsentieren. 


Beispiel 5.2: Nachfolgend betrachten wir ein einfaches Beispiel: 


int main() { 
int i, j=0; 
_Pragma("loopbound min 100 max 100") /x Hinweis an aiT */ 
for (i=0; i <100; i++) { 
if (i<50) jt=i; 
else j+=(ix13) % 42; 
} 
return j; 


} 


Abb. 5.11 (links) zeigt einen Kontrollflussgraphen für dieses kleine Programm. Der 
Kontrollfluss wurde durch start- und exit-Knoten erweitert. 


x4 x2 
x0 start > _main _main: 21 cycles 
x6 _L1: 27 
x19 x7 \ x11 ae = 
x9 = 
L2 L1 10 L3 142 
x20 x14 x16 a 20 
x3 LA L5 _L6: 13 
exit x8 
x5 y 
x18 L6 
x1 


Abb. 5.11 Beispielprogramm: links: Kontrollflussgraph, rechts: WCET g sr der Basisblöcke 


Knoten _L1 entspricht dem Test der for-Schleife, _L3 dem if-Test, _L4 und _L5 
den zwei Fällen des if-Statements und _L6 der Rekonvergenz. Die Variablen x0 
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bis x20 bezeichnen die Ausführungshäufigkeiten der Blöcke und die Anzahl der 
Übergänge zwischen den Blöcken. Beispielsweise haben wir x6 Übergänge von 
Block main zum Block _L1 und führen den Zielblock x7-mal aus. Wir nehmen an, 
dass die Analyse der WCET für die Basisblöcke zu der Liste auf der rechten Seite 
von Abb. 5.11 geführt hat. Dies führt zu dem nachfolgenden Auszug aus der Liste 
der ILP-Randbedingungen. 


01: 21 x2 + 27 x7 + 2 x11 + 2 x14 + 20 x16 + 13 x18 + 20 x19;/*Zielfunktion*/ 
02: x7 - x8 - x6 = ð; /* Randbedingung für Fluss nach _L1 */ 
03: x7 - x9 - x10 = ®; /* Randbedingung für Fluss von _L1 */ 
04: x7 - 101 x9 >= ð; /* Randbedingung für untere Schleifengrenze von _L1 */ 
05: x7 - 101 x9 <= ð; /x Randbedingung für obere Schleifengrenze von _L1 */ 


06: xð - x4 = ð; /* CFG Start-Randbedingung */ 
07: x2 - x4 = @; /x Randbedingung für Fluss nach _main */ 
08: x2 - x6 = ð; /* Randbedingung für Fluss von _main x/ 
OB aks 


Zeile 01 enthält die Zielfunktion. Alle anderen Zeilen enthalten Randbedingun- 
gen, welche die Struktur des Graphen modellieren. Beispielsweise sind die Randbe- 
dingungen für den Knoten _L1 in den Zeilen 02 und 03 angegeben. Die Häufigkeit 
des Verzweigens in diesen Knoten (x6+x8) ist gleich der Anzahl der Ausführungen 
(x7). Die Häufigkeit des Verlassens dieses Knotens (x9+x10) ist ebenfalls gleich der 
Anzahl der Ausführungen (x7). Die Zeilen 04 und 05 korrespondieren zu den Schlei- 
feniterationen. Die Anzahl der Iterationen wurde dem Pragma im Code entnommen. 
Zeile 06 sagt aus, dass die Anzahl der Ausführungen des start-Knotens gleich der 
Anzahl der Verzweigungen in den Code ist. Die übrigen Zeilen beschreiben die 
Struktur in ähnlicher Weise. Vv 


Das so definierte ILP-Problem kann mit einem Standard-ILP-Solver, der die Ziel- 
funktion maximiert, gelöst werden. Das so berechnete Maximum ist eine sichere 
obere Schranke für die gesamte Ausführungszeit. 

Diese Technik der Modellierung von Ausführungszeiten heißt Implicit Path Enu- 
meration Technique (IPET) [344]. Sie vermeidet eine vollständige Aufzählung aller 
möglichen Ausführungspfade. Eine solche Aufzählung würde zu i.d.R. zu sehr vielen 
Pfaden führen. 

In aiT ist auch eine Visualisierung der Ergebnisse in Form annotierter Kontroll- 
flussgraphen verfügbar. Der Entwickler kann diese Graphen analysieren, um das zu 
entwerfende System zu optimieren. aiT besitzt eine Reihe von Einschränkungen, die 
sich aus dem beschriebenen Vorgehen erklären lassen: so werden keine Verdrängun- 
gen durch andere Prozesse, keine Hardware-Unterbrechungen, keine Ein/Ausgaben, 
keine direkten Speichertransfers (DMA) und keine Interferenzen durch andere Hard- 
warekomponenten betrachtet. 

Für die WCET-Analyse von Mehrkern-Systemen existieren nur wenige Ansät- 
ze [265, 266, 287]. Mit neuen probabilistischen Methoden [2] sollen existierende 
Ansätze ergänzt werden. Sie basieren meist auf der Extremwerttheorie [196]. 
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5.2.3 Realzeitkalkiil 


WCET-Berechnungen erlauben es uns, obere Schranken für eine einzelne Ausfüh- 
rung eines Programms zu bestimmen. Die resultierenden Werte reichen aber noch 
nicht aus, um zu garantieren, dass ein Strom von Ereignissen von einer Hardware- 
plattform mit ausreichender Performanz rechtzeitig verarbeitet wird. Dies kann aber 
z.B. für Teile des Internets der Dinge wichtig sein. 

Eine Prüfung auf eine ausreichende Verarbeitungsleistung ist mit Thieles Real- 
zeitkalkül (engl. Real-Time Calculus (RTC)) möglich. Dieser Kalkül basiert auf 
einer Beschreibung der Rate der eingehenden Ereignisse?. Diese Beschreibung um- 
fasst auch Fluktuationen dieser Rate. Zu diesem Zweck werden charakteristische 
Eigenschaften eingehender Ströme von Ereignissen durch ein Tupel von Ankunfts- 
kurven (engl. arrival curves) dargestellt 


@"“(A),@'(A)ER>OAER>0 


@"(A) und @!(A) beschreiben jeweils die maximale bzw. die minimale Anzahl von 
Ereignissen, die in einem Intervall der Länge A eingehen. Es gibt also höchstens 
@"(A) und mindestens @!(A) eingehende Ereignisse in einem Intervall (t,t + A) für 
alle t > 0. Abb. 5.12 beschreibt die Zahl möglicher Ereignisankünfte für mögliche 
Modelle von Ereignisströmen. Bei periodischen Ereignisströmen mit einer Periode 


N 
34 aua eS 3t a =. 
3 Q L----! 2, Q -----! 
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T+J 


Abb. 5.12 Ankunftskurven: links: periodischer Strom; rechts: periodischer Strom mit Jitter J 


T findet in einem Intervall (0,7) maximal ein einzelnes Ereignis statt?. Entspre- 
chend gibt es eine obere Grenze von höchstens zwei ankommenden Ereignissen im 
Zeitintervall (T,2 T). 

Betrachten wir nun die untere Schranke für das Zeitintervall (0, T). Möglicherwei- 
se findet kein einziges Ereignis in diesem Intervall statt. Die untere Schranke ist also 
Null. Im Zeitintervall (T,2 T) muss es mindestens ein Ereignis geben. Daher ist die 
Schranke ebenfalls eins. Für A = 0,5 T gibt es also mindestens Null und maximal ein 
ankommendes Ereignis (siehe Abb. 5.12 (links)). Bei periodischen Ereignisströmen 
mit Jitter J werden die Kurven um diesen Betrag verschoben. Die obere Schranke ist 


? Unsere Darstellung basiert auf Thieles Beitrag im Buch von Zurawski [536]. Entsprechende 
Betrachtungen auf Systemebene heißen Modular Performance Analysis (MPA). 


3 Wir vermeiden hier die subtile Diskussion der Unstetigkeiten für A = n * T. 
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nach links verschoben und die untere Schranke nach rechts. Wir nehmen dabei an, 
dass der Jitter sich nicht im Laufe der Zeit aufsummiert. Wir können uns dazu vor- 
stellen, dass die Taktfrequenz im Prinzip korrekt ist und dass nur einzelne Flanken 
zu früheren oder späteren Zeiten verschoben sind. 

Wir benutzen Striche über den Symbolen (wie in œ) für alle Größen, die Ereignisse 
(engl. events) bezeichnen. 

Auf ähnliche Weise kann die zur Verfügung stehende Bearbeitungs- und Über- 
tragungsleistung durch service functions ß"(6) und 8'(6) beschrieben werden mit 


B"(A,B'(A)ER>0,AER>O0 


Mit dem Intervall [8’,8“] wird modelliert, dass die Bearbeitungsleistung im Laufe 
der Zeit schwanken kann. Abb. 5.13 charakterisiert die Übertragungsleistung ei- 
nes Busses, der nach dem Time Division Multiple Access (TDMA)-Prinzip (siehe 
Seite 193) immer nur innerhalb gewisser Zeitintervalle s für eine Übertragung ge- 
nutzt werden kann. Die Zuteilung findet periodisch alle 7 Zeiteinheiten statt. Das 


Kapazität 
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Abb. 5.13 Bearbeitungs- bzw. Ubertragungsleistung (service functions) eines TDMA-Busses 


Zeitfenster fiir die Zuteilung ist s Zeiteinheiten lang. Wahrend dieses Zeitfensters 
erreicht der Bus eine Bandbreite von b. Die obere Grenze lässt sich ermitteln, wenn 
der Bus zu Beginn der Beobachtung zugeteilt wird. Der Umfang an übertragbaren 
Informationen steigt dann linear an. Die untere Grenze ergibt sich, wenn der Bus zu 
Beginn unserer Beobachtung der Länge A gerade freigegeben wurde. Dann müssen 
wir T — s Zeiteinheiten warten, bis der Bus wieder zugeteilt wird. 

Die Bestimmung der Funktionen @ und £ ist nicht Teil des Realzeitkalküls, son- 
dern sie muss mit separaten Methoden extern erfolgen. Allerdings können Schranken 
für innerhalb des Systems erzeugte Ereignisse aus dem Kalkül abgeleitet werden 
(siehe unten). 

Bislang fehlt noch die Information, welche Arbeitslast (engl. workload) ein 
eintreffendes Ereignis erzeugt. Die Arbeitslast wird im Realzeitkalkül durch weitere 
Funktionen y“(e),y/(e) € R > 0 für jede Folge von e Ereignissen charakterisiert. 
Diese Information kann z.B. aus den Schranken für die Ausführungszeit eines Jobs 
bestimmt werden. Abb. 5.14 zeigt ein Beispiel für diese Funktionen. Dabei wurde 
angenommen, dass pro eingehendem Ereignis drei bis vier Rechenzeiteinheiten zur 
Bearbeitung erforderlich sind. Entsprechend schwankt der Bearbeitungsbedarf für 


276 5 Bewertung und Validierung 


I opia wee 
ı | BCET=3 a oa 
Ce. a 
84 ee 
4- ee 
a T T T > 
1 2 3 e 


Abb. 5.14 Arbeitslast (WCET œ sr kann anstelle der WCET genutzt werden) 


ein einzelnes Ereignis zwischen drei und vier Zeiteinheiten, der Bearbeitungsbedarf 
für zwei Ereignisse zwischen sechs und acht Zeiteinheiten usw. Die gestrichelten 
Linien sind kein Teil der Funktion, da diese nur an ganzzahligen Zeitpunkten definiert 
ist. Die Arbeitslast, die ein eingehender Strom von Ereignissen erfordert, kann nun 
leicht berechnet werden. Obere und untere Schranken werden beschrieben durch die 
Funktionen 


a"(A) = y“(@"(A)) und (5.4) 
a'(A) = y'(@'(A)) (5.5) 


Es sollte ausreichende Bearbeitungs- oder Kommunikationskapazität zur Verfügung 
stehen, um diese Arbeitslast zu bewältigen. Die Anzahl der Ereignisse, die mit der 
verfügbaren Bearbeitungskapazität verarbeitet werden kann, kann berechnet werden 
durch 


B“ (A) = (YY B" (A)) und (5.6) 
B'A) = OBA) (5.7) 


Die Gleichungen (5.6) und (5.7) verwenden die Inverse der Funktionen y” und 
y!, um Schranken der verfügbaren Kapazität (gemessen in realen Zeiteinheiten) in 
Schranken zu wandeln, die durch die Anzahl abarbeitbarer Ereignisse beschrieben 
werden. 

Mit dieser Information kann bestimmt werden, wie Echtzeitkomponenten einen 
eingehenden Ereignisstrom [@’,@“] in einen ausgehenden Ereignisstrom [@",a“ ] 
transformieren. Ebenso kann bestimmt werden, welche Verarbeitungsleistung noch 
für andere Aufgaben bereitsteht. Diese verbleibende Verarbeitungsleistung ergibt 
sich durch die Transformation der service curves [ß',ß"] in service curves [B" , B" | 
(siehe Abb. 5.15). Diese verbleibende Verarbeitungsleistung steht z.B. fiir Aufgaben 
zur Verfügung, die auf demselben Prozessor in Tasks mit niedrigerer Priorität gelöst 
werden. 
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Abb. 5.15 Echtzeitkomponenten transformieren Ereignisströme und Bearbeitungskapazität 


Thiele et al. geben an, wie die ausgehenden Ereignisströme und die verbleibende 
Bearbeitungsleistung berechnet werden können [536]: 


a =[(@"@B")OB'] AB" (5.8) 
a" =[@' OB") @B |B! (5.9) 
BX = (B"-a')o0 (5.10) 
B” = (B'-@")@0 (5.11) 


Dabei sind die Operatoren definiert durch: 


F 88O) = infocucr{ f(t — u) + g(u)} (5.12) 
(FB gO) = suposusit f(t - u) + gw} (5.13) 
(f © g)(t) = supyso{ f(t + u) - gw} (5.14) 
F286) = infusot f(t + u) — gu} (5.15) 


A bezeichnet den Minimum-Operator. 

Im Wesentlichen beschreiben diese Funktionen ausgehende Ströme und Kapa- 
zitäten. Diese Gleichungen wurden aus der Kommunikationstheorie übernommen. 
Beweise zu diesen Gleichungen finden sich in Publikationen zum Netzwerkkalkül 
[328]. Die einfachste Art, diese Gleichungen zu verwenden, ist der Einsatz einer 
Matlab-70o0lbox [560]. 

Diese Theorie ermöglicht auch die Berechnung der Verzögerung, die durch die 
Echtzeitkomponenten verursacht wird und der Puffergröße, die für die Zwischen- 
speicherung ein- und ausgehender Ereignisse benötigt wird. So lassen sich die Perfor- 
manz und weitere Eigenschaften eines Systems aus Informationen über die einzelnen 
Komponenten berechnen. 
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Ein weiterer Ansatz zur Performanzanalyse wurde von Henia, Ernst et al. entwi- 
ckelt. Der sogenannte SymTA/S-Ansatz [211] ersetzt die verschiedenen Kurven aus 
Thieles Ansatz durch Standard-Modelle von Ereignisströmen wie z.B. periodischen 
Ereignisströmen, periodischen Ereignisströmen mit Jitter und periodischen Ereig- 
nisströmen mit Bursts. SymTA/S unterstützt dabei insbesondere die Kombination 
und Integration verschiedener Analysetechniken aus dem Echtzeitbereich. 


5.3 Qualitätsmetriken 


5.3.1 Näherungsweises Rechnen 


In manchen Anwendungen ergibt sich zur Berechnung des bestmöglichen Ergeb- 
nisses ein hoher Bedarf an Ressourcen (wie z.B. Rechenzeit, Energie, Speicher 
usw.). Dabei wird teilweise nicht das bestmögliche Ergebnis benötigt, da kleine 
Abweichungen davon nicht vom Benutzer bemerkt werden. Dies gilt beispielsweise 
für verlustbehaftete Audiokodierung (wie z.B. MP3) sowie verlustbehaftete Video- 
und Bildkodierung (wie z.B. JPEG). Dies kann in einer ressourcenbeschränkten 
Umgebung ausgenutzt werden, um zwischen der Qualität der Ausgabe und dem Res- 
sourcenbedarf auszubalancieren. Dies führt uns zum näherungsweisen Rechnen 
(engl. approximate computing). 


Definition 5.11: Unter dem näherungsweisen Rechnen versteht man Rechenme- 
thoden, bei denen man eine gewisse Abweichung des Ergebnisses vom bestmögli- 
chen Ergebnis toleriert [398]. 


Beim näherungsweisen Rechnen ist es notwendig, die Qualität der Ergebnisse als 
eines der Zielkriterien zu benutzen. Leider ist es nicht einfach, die Qualität von Er- 
gebnissen zu bewerten und es können verschiedene Metriken zum Einsatz kommen. 


5.3.2 Einfache Qualitätskriterien 


Einige einfache Metriken können benutzt werden, wenn das wahre oder das best- 
mögliche Ergebnis bekannt sind. Gegeben seien n Folgenelemente x1,...,x„ eines 
Signals x in diskreter Zeit. Weiterhin nehmen wir an, dass wir statt der echten oder 
der bestmöglichen Werte x1, ..., Xn näherungsweise Werte y1,...,y„ berechnen oder 
messen. 

Damit können wir das mittlere Fehlerquadrat (engl. Mean-Squared Error (MSE)) 
wie folgt definieren: 


Definition 5.12: Das mittlere Fehlerquadrat ist definiert als 
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1 n 

MSE(x,y) = - ) (x - yi)? (5.16) 
n i=l 


Die Wurzel aus dem mittleren Fehlerquadrat (engl. Root-Mean-Squared Error 
(RMSE)) bildet die zweite Metrik: 


Definition 5.13: Die Wurzel aus dem mittleren Fehlerquadrat (RMSE) ist definiert 


als 
RMSE(x,y) = 4| — I, Gi yo? 65.17) 
i=l 


RMSE besitzt dieselbe Dimension wie die Differenz zwischen dem echten und dem 
aktuellen Wert, sollte aber nicht mit dem mittleren Fehler verwechselt werden, der 
wie folgt definiert wird: 


Definition 5.14: Der mittlere Fehler (engl. Mean-Absolute Error (MAE)) ist defi- 
niert durch 


1 n 
MAE(x,y) = 2, u = vil (5.18) 


i=1 


Der MAE ist gleich dem RMSE, wenn die Abweichungen von y vom echten Wert 
x alle gleich sind. Ansonsten betont der RMSE große Abweichungen zwischen den 
beiden Werten (sogenannte Ausreißer). 

Das Signal-zu-Rauschverhältnis (engl. Signal-to-Noise Ratio (SNR)) wurde be- 
reits auf Seite 156 definiert. Als nächstes definieren wir das Spitzen-Signal-zu- 
Rauschverhältnis, welches dem SNR ähnlich ist. Sei x ein Signal, Xmax dessen 
Maximum und y die verrauschte Approximation von x. 


Definition 5.15: Das Spitzen-Signal-zu-Rauschverhältnis (engl. Peak-Signal-to- 
Noise Ratio (PSNR)) ist definiert durch 


aay 

PSNR(x, y) = 10 logy free 5] (5.19) 
Xmax 

= 20 logio eee 5] (5.20) 


PSNR wird wie SNR in Dezibel (dB) gemessen. 


Die genannten Metriken sind leicht zu berechnen, aber sie beziehen den Eindruck, 
den Menschen von den Abweichungen haben, nicht mit ein [316]. Es ist bekannt, 
dass manche Abweichungen zwischen den echten und den berechneten Werten kaum 
bemerkt werden. Dies ist die Basis der verlustbehafteten Kodierungstechniken wie 
MP3, JPEG oder digitaler Fernsehstandards. Keine der bislang betrachteten Metriken 
berücksichtigt die menschlichen Eindrücke. Als nächstes stellen wir den Universal 
Image Quality Index (UIQI) [563] vor, der Änderungen in der Struktur von Bildern 
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zu erfassen sucht, weil das menschliche Auge darauf sehr sensibel reagiert. Wir 
werden die Berechnung dieser Metrik fiir Grauwert-Bilder vorstellen. Verschiedene 
Größen müssen berechnet werden [316]: 


1 n 
Hx = JM (5.21) 
n i=1 
1 n 
Hy = — Di (5.22) 
i=1 
2 [xf 
Ey) = 5 (5.23) 
Hx + My 


Die Gleichungen (5.21) und (5.22) berechnen die durchschnittliche Helligkeit jedes 
der Bilder und aus diesen den Wert €(x, y). Bei Bildern gleicher Helligkeit wird 
€(x, y) den Wert 1 annehmen, ansonsten einen davon verschiedenen Wert. 

Außerdem betrachten wir Abweichungen. Gleichungen (5.24) und (5.25) berech- 
nen den Kontrast jedes der Bilder und daraus den Wert c(x, y). 


1 n 
VE 2, = x)? (5.24) 
1 n 
lan 2,0 - py)? (5.25) 
20x07 
N) (5.26) 
x y 


Bei Bildern gleichen Kontrasts wird c(x, y) den Wert 1 annehmen, ansonsten einen 
davon verschiedenen Wert. Gleichung (5.27) berechnet die Kreuzkorrelation zwi- 
schen den beiden Bildern: 


1 n 
Oxy = ET Ya = Hx)(Yi — Hy) (5.27) 
i=l 
Ox,y 
s(x, y) = (5.28) 
ey 


Nimmt die gemäß Gleichung (5.28) berechnete Größe s(x, y) positive Werte an, so 
gibt es eine gute Korrelation zwischen den beiden Bildern, ansonsten eine inverse 
Korrelation. 

Aus den eingeführten Größen wird nunmehr eine Gesamt-Qualitätsmetrik mittels 
Gleichung (5.29) berechnet. 


2 20% 
CE Se Se 


Hx + My r2 + o? 0x0, 


(5.29) 
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Für identische Bilder wird Q = 1 sein und negativ für invers korrelierte Bilder. 

Es ist nicht sinnvoll, diese Qualitätsmetrik für ganze Bilder zu berechnen, da 
eine inverse Korrelation in einem bestimmten Block schon eine negative Korrelation 
für das gesamte Bild ergibt. Daher wird Gleichung (5.29) immer nur für Blöcke 
von Pixeln berechnet. Aus den O-Werten verschiedener Blöcke wird die globale 
UIQI-Metrik berechnet. 

Als Erweiterung der UIQI-Metrik kann man ein Maß für strukturelle Ähnlichkeit 
in Form des Structural Similarity Index Measure (SSIM)-Wertes berechnen [564]. 

Kühn [316] hat die verschiedenen Metriken verglichen und herausgefunden, dass 
keine dieser Metriken den anderen wirklich überlegen ist. Er empfiehlt, in der Praxis 
mehrere dieser Metriken zu berechnen und diese sorgfältig zu vergleichen. Eine 
Übersicht über einige nützliche Metriken findet sich auch bei Mittal [398]. 

In der digitalen Kommunikationstechnik ist das Bitfehlerverhältnis (engl. Bir 
Error Ratio (BER)) eine wichtige Metrik. 


Definition 5.16: Das Bitfehlerverhältnis (BER) ist der Quotient aus der Anzahl der 
Bitfehler und der Gesamtzahl der übertragenen Bits. 


5.3.3 Kriterien für die Datenanalyse 


Sensoren sind häufig nicht ideal, sondern weisen Fehler auf. Auch müssen aus den 
Messungen von evtl. mehreren Sensoren Schlüsse gezogen werden. Hierzu wer- 
den i.d.R. Datenanalysetechniken beispielsweise aus dem Bereich des maschinellen 
Lernens benötigt (siehe auch Seite 17). Ergebnisse der Datenanalyse sind in der 
Regel mit Unsicherheiten behaftet, sei es durch Unsicherheiten bereits bei den Aus- 
gangsdaten, sei es durch unterschiedliche Analysetechniken. In gewisser Weise ist 
Datenanalyse daher ein Fall von näherungsweisem Rechnen, obwohl dieser Begriff 
in diesem Kontext in der Regel nicht benutzt wird. 

Ein sehr wichtiger Spezialfall der Datenanalyse ist die Klassifikation von Objek- 
ten. Sei X eine Menge von Objekten, die wir klassifizieren möchten. Wir beschränken 
uns hier auf die binäre Klassifikation. 


Beispiel 5.3: Wir betrachten die Suche nach Bernstein an einem Strand. Leider sieht 
weißer Phosphor, der beispielsweise in Form von Rückständen von Bomben am Rand 
der Ostsee gefunden wird, sehr ähnlich wie Bernstein aus. Er fängt aber sehr plötzlich 
an, bei 1300 °C zu brennen, sobald er trocknet. Die Klassifikation von Fundstücken 
als Phosphor oder Bernstein ist daher sehr kritisch und mit hohen Gesundheitsrisiken 
verbunden. Unerfahrene Personen sollten solche Fundstücke nicht berühren. V 


Allgemein sind bei der binären Klassifikation vier Fälle möglich: 


e richtig positiv (engl. true positive (TP)): wir klassifizieren ein Objekt als positiv 
und das ist richtig. Im obigen Beispiel: wir halten ein Fundstück für Bernstein 
und es ist Bernstein. 
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e falsch positiv (engl. false positive (FP)): wir klassifizieren ein Objekt als positiv 
und das ist falsch. Im obigen Beispiel: wir halten Phosphor für Bernstein (eine 
gefährliche Fehleinschätzung). 

e richtig negativ (engl. true negative (TN)): wir klassifizieren ein Objekt als negativ 
und das ist richtig. Im obigen Beispiel: wir halten ein Fundstiick fiir Phosphor 
und es ist Phosphor. 

e falsch negativ (engl. false negative (FN)): wir klassifizieren ein Objekt als negativ 
und das ist falsch. Im Beispiel: wir klassifizieren ein Fundstück als Phosphor und 
es ist Bernstein‘. 


Absolute Zahlen (beispielsweise Anzahlen von gefundenen Objekten) miissen zuein- 
ander in Beziehung gebracht werden. Daher werden die folgenden Metriken definiert: 


Definition 5.17: Unter Genauigkeit (engl. precision) verstehen wir das Verhältnis 


TP 


EEE 5.30 
TP+FP ( ) 


P 
Im Fall der Bernsteinsuche zielen wir auf einen Wert von | (also auf FP = 0), 
weil wir uns nicht verbrennen möchten. Im Zweifelsfall würden wir also ein Objekt 
sicherheitshalber als Phosphor klassifizieren. Mithin müssen wir die Möglichkeit 
falsch negativer Klassifikationen (d.h. FN > 0) akzeptieren, wenn wir eine gute 
Genauigkeit erreichen wollen. Anders ist die Situation beispielsweise bei der Krank- 
heitsdiagnose. Hier zielen wir möglichst auf FN = 0, um keinen Krankheitsfall zu 
übersehen, und akzeptieren dafür eher falsch positive Klassifikationen und dement- 
sprechend p < 1. 


Definition 5.18: Unter Sensitivität (engl. sensitivity oder recall) verstehen wir das 
Verhältnis 


TP 


Sen 31 
"= TP+FN al 


Eine gute Genauigkeit führt wegen FN > 0 tendenziell zu einer schlechteren Sensi- 
tivität. 
Definition 5.19: Unter Korrektklassifikationsrate (engl. accuracy) verstehen wir 
das Verhältnis 

TP+TN 


acc = (5.32) 
TP+FP+TN+FN 


Im Fall der Bernsteinsuche können wir eine nicht-optimale Korrektklassifikationsrate 
akzeptieren, um die Zahl der falsch positiven Werte so gering wie möglich zu halten. 
Wir können daher eine größere Zahl von falsch-negativen Klassifikationen haben. 


4 Ein anderes, aktuelles Beispiel der Anwendung der Klassifikation ist der Test auf eine vorliegende 
COVID-19 Infektion. In diesem Fall sind falsch negative Klassifikationen gefährlich. 
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Definition 5.20: Unter Spezifizität (engl. specificity) verstehen wir das Verhältnis 


TN 


IN+FP G37) 


Specificity = 
Definition 5.21: Der FI score oder das F-Maß ist definiert als das harmonische 


Mittel von Genauigkeit und Sensitivität: 


p*r 
ptr 


Fl=2 


(5.34) 


In einem allgemeineren Kontext ist Quality of Service (QoS) eine weitere bekann- 
te Metrik. Häufig bezieht sich diese Metrik auf die Qualität von Kommunikations- 
kanälen, für die Bitfehlerquotienten, Latenzzeit und Bandbreite mögliche Kriterien 
sind. 

In einem noch größeren Zusammenhang könnten wir nicht nur technische Para- 
meter betrachten, sondern uns insgesamt auf die Erfahrung des Benutzers beziehen. 
Diese wird in der Metrik Quality of Experience (QoE) erfasst. Sie schließt alle 
Aspekte der Erfahrungen von Nutzern ein. Es gibt eine Anzahl von Metriken, die 
alle versuchen, die Erfahrungen von Nutzern zu messen [401]. 


5.4 Modelle des Energieverbrauchs und der Leistungsaufnahme 


5.4.1 Allgemeine Eigenschaften 


Energiemodelle und Leistungsmodelle sind wichtig, um die entsprechenden Ziele 
bewerten zu können und um Optimierungen vorzunehmen, welche diese Größen 
reduzieren sollen. Sie werden auch für Optimierungen verwendet, die Betriebstem- 
peraturen verringern und die Zuverlässigkeit verbessern sollen. Ein Modell der Leis- 
tungsaufnahme wird auch im power management benötigt (siehe Seite 404). 

Energie- und Leistungsmodelle sind eng miteinander verwandt, wie in Gleichung 
(3.13) zu sehen ist. Gemäß dieser Gleichung ergeben sich Energiemodelle häufig 
durch Integration von Leistungswerten über der Zeit. Umgekehrt kann aus Energie- 
werten auch mittlere Leistungsaufnahme in einem Zeitintervall bestimmt werden. 
Wir können zwischen zwei Klassen von Modellen unterscheiden: 


1. Die Klasse der Modelle, die auf Messungen auf realer Hardware basiert. Mes- 
sungen können sehr genau sein, aber sie können nur bei tatsächlich vorhandener 
Hardware durchgeführt werden. Die Messung von Spannungen ist üblicherweise 
sehr einfach und bedarf keiner komplexen Prozeduren. 

Die Messung von Strömen kann mit Stromzangen oder mit Shunt-Widerständen 
erfolgen. 


« Stromzangen müssen eines der Stromversorgungskabel umfassen. Sie messen 
das Magnetfeld, welches durch den Strom verursacht wird, der durch das Kabel 
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flieBt. Der Vorteil dieses Verfahrens liegt darin, dass die Stromversorgung 
nicht unterbrochen werden muss und dass die Stromversorgung während der 
Messung unverändert bleibt. Ein Nachteil liegt darin, dass diese Messungen 
meist nicht sehr genau sind. 

Zur Messung des Stromes könnte man ein einfaches Strommessgerät (Ampere- 
meter) benutzen, welches man in die Stromzuführung einschleift, d.h. über das 
der gesamte Strom fließt. Ein Nachteil ist, dass die Schaltung dann bei abge- 
klemmtem Messgerät gar nicht arbeitet und dass lange Leitungen zum Strom- 
messgerät möglicherweise zusätzliche Störungen verursachen. Daher arbeitet 
man lieber mit einem Shunt-Widerstand, wie in Abb. 5.16 (links) zu sehen. 
Aufgrund des Shunt-Widerstandes werden Ströme, die in das zu testende Gerät 


V V 
Shunt Shunt 
Spannungs- Zu testen- Spannungs- Zu testen- 
quelle des Gerät quelle m | des Gerät 


Abb. 5.16 Strommessung: links: 2-Draht-Verbindung; rechts: Rückkopplung über geregelte Span- 
nungsquelle 


fließen, einen Spannungsabfall über eben diesem Widerstand erzeugen. Diese 
Spannung kann gemessen werden und mit Hilfe des Ohmschen Gesetzes kann 
der Strom ausgerechnet werden. Die Dimensionierung des Shunt-Widerstandes 
bedarf einiger Überlegung. Wenn der Widerstandswert zu groß ist, dann wird 
die Spannung am zu testenden Gerät eventuell zu klein und das Gerät funktio- 
niert möglicherweise gar nicht mehr. Wenn der Widerstandswert zu klein ist, 
dann wird die Spannung über dem Shunt zu klein, um zuverlässig gemessen 
zu werden und wird ggf. durch Rauschen beeinflusst werden. Es hängt vom 
Strom in das Gerät ab, welcher Widerstandswert geeignet ist. Wenn der Strom 
sich stark ändert, kann es sogar notwendig sein, mehrere Shunt-Widerstände 
zu benutzen und zwischen diesen abhängig vom Strom umzuschalten. 

Das Problem des Spannungsabfalls über dem Shunt-Widerstand kann teilwei- 
se vermieden werden, wenn eine geregelte Spannungsversorgung benutzt wird 
und wenn der Shunt-Widerstand in die Rückkopplungsschleife des Spannungs- 
reglers integriert wird, wie dies in Abb. 5.16 zu sehen ist. Der Spannungsregler 
wird dann versuchen, die Spannung über dem Gerät auf dem nominalen Wert 
zu halten. Allerdings fließt so auch der Strom in den Regeleineingang des 
Spannungsreglers über den Shunt-Widerstand und verfälscht so die abgelese- 
ne Spannung. 
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Leider gibt es in der Regel keinen separaten Stromversorgungsanschluss fiir jede 
Komponente im zu testenden Gerät und wir können daher nur die Summe des 
Strombedarfs der einzelnen Komponenten bestimmen. Wir können jedoch versu- 
chen, das Gerät auf bestimmte Weise zu stimulieren, sodass wir den Strombedarf 
einzelner Komponenten bestimmen können. 

2. Die Klasse der Modelle, die nur „virtuell”, d.h. auf Papier, in einem Rechner 
oder in Gedanken existieren. Modelle können auch dann benutzt werden, wenn 
die echte Hardware nicht zur Verfügung steht und stattdessen eine Formel oder 
ein Rechnerprogramm benutzt wird. Solche Modelle können aber sehr ungenau 
sein und sie müssen daher überprüft werden, ansonsten blieben sie fragwürdig. 
Zwei Methoden der Überprüfung werden für viele Leistungs- und Energiemodelle 
eingesetzt: 


« Die Ergebnisse können mit überprüften Modellen einer niedrigeren Abstrak- 
tionsebene verglichen werden. 

e Die Ergebnisse können mit Messungen an echten Geräten verglichen werden, 
was zu einem hybriden Modell führt. Auf den Basis der Messungen müssen 
Modellparameter so gewählt werden, dass sich eine möglichst gute Überein- 
stimmung zwischen dem Modell und den Messungen ergibt. Häufig werden 
lineare Modelle gewählt und die Modellparameter werden mit der Methode 
der kleinsten Quadrate gewählt, was zur kleinsten Abweichung gemäß MSE- 
Metrik (siehe Gleichung (5.16)) führt. Ein solcher Abgleich zwischen dem 
Modell und den Messwerten wird durch mathematische Werkzeuge wie z.B. 
MATLAB® unterstützt. Eine neuere Technik hierfür besteht aus dem Einsatz 
von Methoden des Maschinellen Lernens. Beispielsweise beschreiben Falken- 
berg et al. [161] den Einsatz Maschinellen Lernens zur Bestimmung eines 
Modells für die Sendeleistung von Mobilfunkgeräten. 


Jedes Leistungsmodell abstrahiert in gewissem Umfang von den Details einer 
physischen Realisierung: manche Details werden berücksichtigt, andere wiederum 
nicht. Bei der Wahl eines Leistungsmodells muss man sich daher fragen, ob die 
gerade relevanten Details berücksichtigt sind. Beispielsweise ist die Alterung häufig 
nicht modelliert. Aus diesem Grund müssen Modelle für die wichtigen Details 
ggf. miteinander zu einem Gesamtmodell kombiniert werden. Daher werden wir in 
diesem Abschnitt repräsentative Modelle der Leistungsaufnahme vorstellen und wir 
setzen darauf, dass Leser bei Bedarf aus diesen Modellen ein neues Modell für die 
jeweils benötigte Aufgabe erzeugen. 


5.4.2 Energiemodell für Speicher 


Im Abschnitt über Speicherhardware (siehe Seite 184) wurde bereits beschrieben, 
dass die Leistungsaufnahme und der Energieverbrauch von Caches und anderen 
Speichern mit CACTI [589, 409] bestimmt werden kann. CACTI basiert auf einem 
abstrakten Chiplayout des Speichers, extrahiert Kapazitäten aus diesem Layout und 
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berechnet daraus Zugriffszeiten, Zykluszeiten, Fläche, Leckströme und die dyna- 
mische Leistungsaufnahme. CACTI wurde anhand von Speichermodellen auf einer 
detaillierteren Ebene überprüft. Hierfür wurden SPICE-Modelle benutzt [519]. Ge- 
genwärtig (d.h. im Jahr 2020) ist die jüngste Version von CACTI (Version 6.5) 
erhältlich von http://www.hpl.hp.com/research/cacti/>. Die letzten Erweiterungen 
betreffen die Modellierung von Leitungen in Chips, von kontextabhängigen Spei- 
cherzugriffen, von Leitungstreibern und von Leitungsempfängern. Darüber hinaus 
können Architektur- wie auch technologische Parameter spezifiziert werden. 


5.4.3 Energiemodell für Maschinenbefehle 


Eines der ersten Energiemodelle für Maschinenbefehle stammt von Tiwari [543]. 
Dieses Modell unterscheidet zwischen Basiskosten von Maschinenbefehlen und Kos- 
ten, die durch den Wechsel von einem Befehl zum nächsten entstehen. Basiskosten 
modellieren die Energie, die pro Ausführung eines Maschinenbefehls verbraucht 
wird, wenn eine unendliche Folge von diesen Befehlen ausgeführt wird. Basiskosten 
können in der Praxis bestimmt werden, indem eine große Anzahl von identischen Be- 
fehlen nacheinander ausgeführt werden und anschließend ein Sprung zurück an den 
Anfang erfolgt. Die Anzahl muss so groß sein, dass der Effekt des Sprungs vernach- 
lässigt werden kann. Dabei müssen die Programme so konzipiert sein, dass keine 
Wartezyklen (z.B. auf den Speicher) auftreten. Dazu müssen ggf. NOOP-Befehle 
eingefügt werden, deren Effekt später wieder herausgerechnet wird. 

Die Kosten des Wechsels zwischen verschiedenen Befehlen modellieren zusätz- 
liche Energie, die beispielsweise dafür benötigt wird, funktionelle Einheiten an- und 
abzuschalten. Diese Kosten berücksichtigen den Einfluss des Anfangszustandes auf 
den Gesamtenergieverbrauch eines Befehls. Sie können berechnet werden, indem 
Programme mit alternierenden Maschinenbefehlen ausgeführt werden. 

Basiskosten und Kosten für Befehlswechsel werden für Programme berechnet, 
die keine Cachefehler erzeugen. Der Effekt von Cachefehlern muss hinzu gerechnet 
werden, indem die Cachefehlerrate und die Energie für Speicherzugriffe einbezogen 
werden. Dabei kann die Energie für Speicherzugriffe bei nicht-homogenem Speicher 
von den jeweils benutzten Adressen abhängen. Bei Tiwari werden diese Adressen 
nicht statisch vorhergesagt. Somit kann die Energie für Speicherzugriffe bei nicht- 
homogenem Speicher nur durch eine Ausführung des Programms bestimmt werden. 

Das Modell von Tiwari wurde u.a. auf zwei reale Systeme angewendet, nämlich 
einen Intel 486 DX2- und einen Fujitsu SPARClite 934-Prozessor. Messungen an 
den realen Systemen wurden benutzt, um das Modell zu kalibrieren. 


5 Der Zugriff über diese Adresse wird empfohlen, da es auch andere Werkzeuge mit demselben 
Namen gibt. Derzeit steht eine anpassbare C++-Version zur Verfügung, ein Webinterface existiert 
i. Ggs. zu früheren Jahren nicht mehr. 
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5.4.4 Energiemodell fiir Prozessoreinheiten 


Das Energieermittlungswerkzeug Wattch [70] ermittelt Schätzungen für den Ener- 
gieverbrauch von Mikroprozessorsystemen auf Architekturebene, ohne detaillierte 
Kenntnisse über die Schaltungs- oder Layoutebene zu benötigen. Wattch benutzt den 
Simulator SimpleScalar, um Prozessoren zu simulieren. SimpleScalar kann so konfi- 
guriert werden, dass der jeweils benutzte Prozessor so genau wie möglich abgebildet 
wird. Die Anzahl der Fließbandstufen und die funktionellen Einheiten werden typi- 
scherweise korrekt modelliert, i. Ggs. zu mehr spezialisierten Eigenschaften. Wattch 
basiert auf der detaillierten Information des Energieverbrauchs der verschiedenen 
funktionellen Einheiten, die man im Mikroprozessor findet. Während der Ausfüh- 
rung merkt sich SimpleScalar, welche funktionellen Einheiten benutzt werden und 
berechnet daraus den Gesamt-Energieverbrauch. 

Wattch benötigt wesentlich mehr Informationen über die Prozessorarchitektur 
als Tiwaris Model auf Befehlssatzebene. Beispielsweise enthält Wattch ein eigenes 
detailliertes Modell des Energieverbrauchs in Speichern. Auch wird der Takt explizit 
berücksichtigt, einschließlich bedingter Taktung, soweit diese eingesetzt wird. In der 
ursprünglichen Publikation [70] gibt es Angaben zur Überprüfung des Modells 
anhand von drei verschiedenen Prozessoren. 


5.4.5 Energiemodell für Prozessor und Speicher 


Als nächstes betrachten wir ein Energiemodell [511], welches hinsichtlich der De- 
taillierung der Komponenten zwischen dem von Tiwari und Wattch liegt und somit 
einen Kompromiss zwischen beiden darstellt. In diesem Modell betrachten wir die 
Summe des Energieverbrauchs in der CPU und im Speicher, jeweils aufgeteilt in den 
Einfluss der Befehle und der Daten: 


Erotal = Ecpu_instr + Ecpu_data + Emem_instr + Emem_data (5.35) 


Jeder der vier Terme wird aus detaillierten Gleichungen berechnet. Die folgende 
Notation wird in diesen Gleichungen benutzt: m ist die Anzahl der betrachteten Be- 
fehle, die Funktion w(b) liefert die Anzahl von Einsen in ihrem Argument (entweder 
Befehl oder Datum), die Funktion h(b}, b2) liefert den Hamming-Abstand zwischen 
den beiden Argumenten, dir bezeichnet die Richtung eines Datentransfers und a; so- 
wie ß; (i € {1..10}) sind Konstanten, die aus der Optimierung der Modellparameter 
resultieren. Damit berechnen wir E.py data Wie folgt: 


Eepu_dara = I, {as + w(DAddr;) + Bs * h(DAddr;-ı, DAddr;) 
i=1 


+@6,dir * w(Data;) + B6,dir * h(Data;-1, Data;) } (5.36) 
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wobei Data; der Datenwert ist, der in Befehl i benutzt wird, und DAddr; ist dessen 
Adresse. 

Der Term Emem_data ist nur dann relevant, wenn tatsächlich auf den Speicher zuge- 
griffen wird: 


Emem_data = { BaseM em(DataM em, dir, Word_width) 
i=l 
+a * w(DAddr;) + By x h(DAddr;_ı, DAddr;) (5.37) 


+a0,air * w(Data;) + Bio,air * h(Data;-1, Data;) } 


wobei BaseMem die Basiskosten fiir den Speicherzugriff mit Richtung dir sind. 
Der Term Emem_instr kann wie folgt berechnet werden: 


Ememänstr = > { BaseMem(Instr Mem, Word_width;) 
i=l 
+a7 * w(I Addr;) + B7 * h(I Addr;-ı, [Addr;) (5.38) 


+ag * w(IData;) + Bg * h(IData;-1,1Data;) } 


wobei BaseM em die Basiskosten für den Befehlsspeicherzugriff sind, Addr; ist die 
Adresse des Befehls und /Data; ist der Befehl i selbst. 
Der Term Ecpu_instr Kann aus der folgenden Gleichung berechnet werden: 


Eepu_instr = oy { BaseCPU(Opcode;) + FUChange(Instr;_,,Instr;) 
i=l 
+a4 * w(IAddr;) + B4 * h([Addr;_,, 1Addr;) 


+ Š (an + w(Immi; j) + Bi * h(lmm;-ı,;, Imm; ,;)) (5.39) 
j=l 


t 
+ > (a2 * w(Regi k) + Bo * h(Regi-ı.x, Regi.x)) 
k=1 


t 
+ > (a; x w(RegVal; x) + B3 * h(RegVal;_, x,RegVal; x) } 
k=1 


wobei BaseC PU die Basiskosten für den Befehlscode Opcode; sind. FUChange(..) 
stellt den Energieverbrauch für den Übergang von Befehl i — 1 zu Befehl i dar. Imm 
modelliert den Einfluss von bis zu s Direktoperanden per Befehl. Reg; , bezieht 
sich auf die Registernummern von bis zu t Registern pro Befehl und RegVal; k 
modellieren bis zu t Registerwerte pro Befehl. 

Zur Bestimmung der Konstanten wurden spezielle Befehlssequenzen entworfen. 
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Beispiel 5.4: Energieverbrauchsbestimmung von load word (1w)-Befehlen: 


start: lw R1, address /* load word */ 
x /* lw-Befehl 50-100-fach wiederholt */ 
bra start /x zurück zum Anfang */ 


Der Energieverbrauch des Rücksprungs kann vernachlässigt werden. Der Einfluss 
der Adressen, Registernummern und Registerinhalte kann durch Variation dieser 
Werte bestimmt werden: wir setzen diese Werte zunächst auf Null und erhöhen dann 
inkrementell die Anzahl der Einsen in der Bitvektordarstellung. V 


In unseren Experimenten wurden die Konstanten durch eine lineare Regression 
bestimmt. Alternativ hätte Maschinelles Lernen benutzt werden können. Es ergab 
sich ein signifikanter Einfluss der Anzahl der Einsen in der Bitvektordarstellung der 
Daten, der in Tiwaris Modell nicht erfasst werden kann. 


5.4.6 Energiemodell fiir eine Anwendung 


Die Odroid XU3-Plattform [203] (siehe 
Abb. 5.17) besitzt mehrere Strom- und Span- 
nungssensoren. Diese Sensoren ermöglichen 
eine präzise Messung der Leistungsaufnahme 
während der Ausführung von Anwendungen, 
wobei die Leistungsaufnahme der beiden Ar- 
ten von ARM®-Prozessorkernen, der GPU 
und des DRAMs einzeln gemessen werden 
können. Diese Sensoren werden in mehreren RE 
Arbeiten genutzt, um verlässliche Angaben 
zum Energieverbrauch zu machen. Beispiels- 
weise haben Neugebauer et al. [418] diese Plattform in ihre Exploration des Ent- 
wurfsraums für eine Anwendung integriert. Diese Exploration auf der Basis eines 
evolutionären Algorithmus wird in Abb. 5.18 gezeigt. 


Abb. 5.17 Odroid XU3 
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Abb. 5.18 Evolutionärer Algorithmus, Fitness-Berechnung auf der Basis von Messungen 
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Die Bewertung einer bestimmten Lösung des Entwurfsproblems basiert auf der 
Messung von Strömen während der Ausführung der Anwendung auf dem XU3. 
Damit ist es möglich, Energiemodelle mit unbekannter Genauigkeit zu vermei- 
den. Der resultierende optimierte Algorithmus wurde von Neugebauer innerhalb 
des cyber-physikalischen PAMONO-Systems eingesetzt [418]. PAMONO ist in der 
Lage, mittels des sogenannten Plasmon-Effekts Bio-Viren zu erkennen. Gerade in 
Pandemie-Zeiten könnte es ein großer Vorteil sein, wenn es möglich wäre, Viren 
innerhalb von kurzen Zeitspannen zu detektieren. 

Die Odroid-XU3-Plattform ist leider nicht mehr erhältlich. Sie wurde durch eine 
Plattform ohne Stromsensoren ersetzt. 


5.4.7 Energiemodell für mehrere Anwendungen und 
Hardware-Multithreading 


Eine Analyse der Ausführung von mehreren Anwendungen wurde von Kerrison 
und Eder durchgeführt [291]. Sie benutzten dafür den XMOS XS1-L Prozessor, 
der zur Unterstützung von Echtzeitanwendungen ein Multithreading in Hardware 
realisiert. Er ist in der Lage, einen schnellen Kontextwechsel zwischen vier An- 
wendungen durchzuführen. Eine der wissenschaftlichen Fragestellungen war: wie 
viel kostet der hardwaremäßige Kontextwechsel, z.B. für das Bewertungskriterium 
Energieverbrauch? 

Aufgrund der Verfügbarkeit von realer Hardware konnte diese Frage durch Mes- 
sungen beantwortet werden. Die Leistungsaufnahme des XMOS XS1-L wurde 
mit einem Shunt-Widerstand gemessen, der in die Stromzuführung einfügt wur- 
de und dessen Spannungsabfall mit einem INA219-Leistungsmessungs-Chip (sie- 
he http://www.ti.com/product/ina219) bestimmt wurde. Die auf dem XMOS XS1-L 
ausgeführte Software wurde durch einen zweiten Prozessor gesteuert. Die beste Ener- 
gieeffizienz wurde erreicht, wenn alle vier Hardware-Threads genutzt wurden. Aller- 
dings führt das Hardware-Multithreading zu vielen Lade- bzw. Entlade-Operationen 
und einer entsprechenden Leistungsaufnahme. Diese hängt von den jeweils ausge- 
führten Befehlen ab. 

Das Ergebnis einer Analyse der Abhängigkeit der Leistungsaufnahme bei Be- 
fehlsausführung ist für den Fall von 8-Bit-Daten in Abb. 5.19 zu sehen. Die zwei 
Dimensionen des Diagramms stellen die Maschinenbefehle dar, die in den geraden 
bzw. ungeraden Threads ausgeführt werden. Gestrichelte Linien grenzen Bereiche 
mit einer unterschiedlichen Anzahl von Operanden voneinander ab. Befehle mit drei 
oder mehr Operanden sind in jedem Diagramm rechts bzw. oben aufgeführt. Es ist 
deutlich zu sehen, dass die Leistungsaufnahme mit der Anzahl der Operanden steigt. 

Abb. 5.20 zeigt die entsprechenden Ergebnisse für 16-Bit-Daten. Abb. 5.20 ver- 
deutlicht, dass die Verarbeitung von 16-Bit-Daten mehr Leistung benötigt, als die von 
8-Bit-Daten. Kerrison et al. benutzen diese Ergebnisse, um Software eingebetteter 
Systeme zu optimieren. So kann man mit diesen Ergebnissen beispielsweise ent- 
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Abb. 5.19 Oben: Leistungsaufnahme für Multithreading bei 8-Bit-Daten, vertikal: Befehle in gera- 
den Threads, horizontal: Befehle in ungeraden Threads; Unten: Farbcodierung von Temperaturen; 
©Kerrison, Eder, 2008 


scheiden, ob byte- oder wortweise Speicherzugriffe energetisch günstiger sind oder 
ob die lokale Speicherung von Registern gegenüber von Speicherzugriffen Vorteile 
bringt. 
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Abb. 5.20 Oben: Leistungsaufnahme für Multithreading bei 16-Bit-Daten; Unten: Farbcodierung 
von Temperaturen; ©Kerrison, Eder, 2008 


5.4.8 Energiemodell für Android-Mobiltelefone 


Zhang et al. [611] beschreiben eine Technik zur Erzeugung eines Energiemodells 
für ein Android-Mobiltelefon, die PowerBooter genannt wird. Diese Technik basiert 
auf der Gleichung (5.40). 
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E = (Bun * freqn + Bul * freq) * util + Bopu * CPUon 
+ßpr * brightness + BGon * GPS_on + Bası * GPS_sl 
+ßwiri_ı * WiFi, + Bwiri_n * WiFin + P3G_idle * 3Gidle 
+ß3G_FACH * 3Gracu + BsG_DcH * 3GDcH (5-40) 

mit 
ß.. : zu bestimmende Konstanten 
freq: CPU-Frequenzen 
util : CPU-Auslastung 
CPUon : Prozessor eingeschaltet? 
brightness : berücksichtigt die Helligkeit der Anzeige 
GPS.. : bezieht sich auf die GPS-Benutzung 
WiFi, : Zeit, in der WLAN im langsamen Modus ist 
WiFi, : Zeit, in der WLAN im schnellen Modus ist 
3G3G_idle : Zeit, in der 3G-Funk unbeschäftigt ist 
3GracHy : Zeit, in der ein gemeinsamer 3G-Kanal benutzt wird 


3GpcH : Zeit, in der ein dedizierter 3G-Kanal benutzt wird 


Es wird deutlich, dass PowerBooter von den Details der Hardware abstrahiert. 
Die Gleichung (5.40) modelliert auch die Kommunikation, die in den bislang 
betrachteten Modellen nicht explizit vorkam. Die Parameter werden wie in den 
bislang beschriebenen Modellen durch Messungen und Parameteroptimierungen 
bestimmt. Die Messungen wurden mit dem Monsoon-Leistungsmessgerat (siehe 
http://www.msoon.com/LabEquipment/PowerMonitor/) vorgenommen. 

Das gewonnene Modell erlaubt in Kombination mit dem Batteriemodell eine Vor- 
hersage der Batterielaufzeit. Die resultierende Information wird einem Werkzeug mit 
dem Namen PowerTutor übermittelt. Mit diesem Werkzeug sollen Anwendungen an 
verschiedene Hardwareplattformen angepasst werden können und Anwendungspro- 
grammierer sollen Energiespartechniken nutzen können, ohne dass sie sich mit den 
Besonderheiten der jeweiligen Plattformen intensiv beschäftigen müssen. 

Ein weiteres Modell des Energieverbrauchs in Mobiltelefonen wurde von Dusza 
et al. [144] publiziert. Darüber hinaus gibt es auch kommerzielle Werkzeuge zur 
Analyse des Energieverbrauchs bzw. der Leistungsaufnahme. 

Alle bislang vorgestellten Energiemodelle zielen auf die Vorhersage der durch- 
schnittlichen Leistungsaufnahme bzw. des durchschnittlichen Energieverbrauchs. 
Dabei erfolgt die Durchschnittsbildung i.d.R. für bestimmte Eingaben oder Anfangs- 
zustände. Durchschnittliche Werte sind hilfreich, um thermisches Verhalten oder die 
Batterielaufzeit über bestimmte Zeitintervalle vorherzusagen. 
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5.4.9 Größtmöglicher Energieverbrauch 


In manchen Kontexten sind dagegen der größtmögliche Energieverbrauch oder die 
größtmögliche Leistungsaufnahme interessant. 


Definition 5.22: Der größtmögliche Energieverbrauch (engl. Worst Case Energy 
Consumption (WCEC)) eines eingebetteten Systems ist das Maximum des Energie- 
verbrauchs, der für alle Eingaben und alle Anfangszustände möglich ist. 


Definition 5.23: Die größtmögliche Leistungsaufnahme (engl. Worst Case Power 
Consumption (WCPC)) eines eingebetteten Systems ist das Maximum der Leis- 
tungsaufnahme, die für alle Eingaben und alle Anfangszustände möglich ist. 


Die größtmögliche Leistungsaufnahme spielt bei der Dimensionierung der Verbin- 
dungen und der Stromversorgung eine Rolle. Der größtmögliche Energieverbrauch ist 
für die Wahl eines Batteriesystems relevant. Dieses muss die WCEC-Anforderungen 
erfüllen. Eine sichere obere Schranke für die WCEC kann wie folgt berechnet wer- 
den: 


WCET 
WCEC < / WCPC dt = WCET x» WCPC (5.41) 
0 


Jayaseelan et al. [272], Pallister et al. [443] und Wägemann et al. [558] haben 
Methoden zur Bestimmungen engerer Schranken vorgeschlagen. 


5.5 Thermische Modelle 


Das Streben nach höherer Leistung eingebetteter Systeme macht es wahrscheinli- 
cher, dass Komponenten im Betrieb heiß werden. Die Temperaturen der einzelnen 
Komponenten eines eingebetteten Systems haben einen großen Einfluss auf ihre 
Verwendbarkeit, z.B. auf die Qualität von Sensorwerten. Überhitzte Komponenten 
können auch dazu führen, dass das betroffene eingebettete System selbst ganz aus- 
fällt oder dass andere Systeme geschädigt werden. Ein Beispiel hierfür wäre eine 
entstehende Brandgefahr. Aber auch wenn kein direkter Ausfall vorliegt, können 
überhitzte Komponenten andere Folgen haben. Beispielsweise kann die Lebensdau- 
er eines Systems durch Überhitzung erheblich sinken (siehe Gleichung (5.73) auf 
Seite 309). Auch kann es notwendig sein, Teile von Silizium-Chips von der Strom- 
versorgung zu trennen, um Überhitzung zu vermeiden. Dies wurde unter dem Begriff 
dark silicon bekannt [153]. 

Das thermische Verhalten eingebetteter Systeme hängt eng mit der Umwandlung 
von elektrischer Energie in Wärme zusammen. Daher sind Temperaturmodelle eng 
mit Energiemodellen verwandt. Grundlage für Temperaturmodelle sind physikali- 
sche Gesetze®. 


6 Wir benutzen hier das Symbol @ zur Bezeichnung von Temperaturen, um eine Verwechslung mit 
Perioden zu vermeiden, für die das Symbol 7 verwendet wird. 
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5.5.1 Stationäres Verhalten 


Wir betrachten eine homogene Schicht aus einem 
bestimmten Material der Fläche (des Querschnitts) 
A und der Dicke L (siehe Abb. 5.21). Wir nehmen 
an, dass es zwischen den gegenüberliegenden Seiten 
eine Temperaturdifferenz A@ gibt. Weiterhin setzen 
wir voraus, dass sich die Wärme in alle Richtun- Abb. 5.21 Schicht der Dicke L 
gen gleich ausbreitet (Isotropie) und dass wir uns 
im stationären (eingeschwungenen) Zustand befinden. Unsere Aussagen gelten 
näherungsweise für den Fall, dass die Fläche A groß gegenüber der Dicke L ist. 
Wir ignorieren dementsprechend Effekte, die sich an den Rändern der Fläche erge- 
ben. Dann ist die thermische Leistung, die zwischen den gegenüberliegenden Seiten 
transferiert wird, gleich 


A0 x A 


Pın=K mit: (5.42) 


P;n : transferierte thermische Leistung x : Warmeleitfahigkeit A : Fläche 
A0 : Temperaturdifferenz L : Dicke 


Dieser Zusammenhang heißt auch Fouriersches Gesetz. 


Definition 5.24: Aufgrund von Gleichung (5.42) definieren wir die Wärmeleitfä- 
higkeit (auch Wärmeleitzahl, spezifisches Wärmeleitvermögen, thermische Leit- 
fähigkeit oder englisch thermal conductivity genannt) x als die thermische Leistung 
P;n, die durch eine Schicht der Dicke 1 und der Fläche 1 fließt, wenn sich die Tem- 
peraturen an den Enden um eine Temperatureinheit unterscheiden (jeweils in den 
benutzten Einheiten gemessen). 


Anstelle von « wird häufig das Symbol A benutzt. « ist abhängig vom Material 
und den Umgebungsbedingungen. Tabelle 5.1 enthält Werte von « für verschiedene 
Materialien und Umgebungsbedingungen. Weitere Informationen zur Abhängigkeit 
von den Umgebungsbedingungen sind in den zitierten Quellen aufgeführt. 


Tabelle 5.1 Näherungsweise thermische Eigenschaften für Luft, Kupfer und Silizium 


Material K: Wärmeleitfähigkeit| cp: spezifische Wärme | cy: Volumetrische 
Wärmekapazität 

(WK m) JK g)) IK m”) 
Luft (25°C) 0.025 [583] 1.012 [576] 1.21 * 10° [576] 
Kupfer 401 [583] 0.385 [576, 567] 3.45 * 10° [576] 
Silizium (~ 26 °C) 148 [148] 0.705 [148, 567] 1.64* 10° [148]? 


a Aus Gleichung (5.57) berechnet 
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Definition 5.25: Das Wärmeleitvermögen [169] (engl. thermal conductance) ist 
definiert als die thermische Energie, die durch eine Schicht pro Zeiteinheit transferiert 
wird, wenn die beiden Enden eine Temperaturdifferenz von einer Temperatureinheit 
(typischerweise in Kelvin gemessen) besitzen. 


Aus Gleichung (5.42) folgt 
— =k*— (5.43) 


Der reziproke Wert dieser Größe heißt thermischer Widerstand (auch Warmeleit- 
widerstand) R;n: 


re (5.44) 


Lemma 5.1: Thermische Widerstände addieren sich wie elektrische Widerstände. 
Wir können thermisches Verhalten analog zu elektrischem Verhalten modellieren. 


Beispiel 5.5: Wir betrachten einen Mikroprozessor, der eine thermische Leistung P;n 
erzeugt, einen thermischen Widerstand R;n,chip des Prozessorchips und thermischen 
Widerstand Ryn fan des Lüfters (siehe Abb. 5.22). 


Abb. 5.22 Thermisches Modell eines 


Rin,chi 
Mikroprozessors mit Liifter 1, CHIP 


P A@ 
rO 
í Rth fan NA 
Masse=Referenztemperatur 
Es gilt 
AO = Rin * Pin (5.45) 
Rın = Rth,chip + Rth.fan (5.46) 
Als Beispiel betrachten wir die folgenden Werte: 
Rın,chip = 0.4 W/K (5.47) 
Rın,fan = 0.3 W/K (5.48) 
Pin = 10W (5.49) 
Daraus errechnen wir: 
A@=7K (5.50) 
Afan = 3K (5.51) 
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Die Leistungsaufnahme und das Wärmeleitvermögen liefern Anhaltspunkte für die 
Berechnung der sogenannten Thermal Design Power (TDP). 


Definition 5.26 ([584]): Die Thermal Design Power (TDP) ist die maximale thermi- 
sche Leistung einer Rechnerkomponente, für die das Kühlsystem entworfen wurde. 
Die TDP dient anstelle der echten Leistungsaufnahme als nominelle Referenz für 
den Entwurf des Kühlsystems. 


Wir könnten versuchen, die TDP aus der WCPC und daraus folgend den ma- 
ximalen Temperaturen sowie dem thermischen Widerstand zu berechnen. Häufig 
entsprechen die publizierten TDP-Werte aber nicht der WCPC, sondern sind nied- 
riger angesetzt. Aus diesem Grund werden Temperatursensoren benötigt, um einen 
sicheren Betrieb zu gewährleisten. Notfalls müssen funktionelle Bereiche abgeschal- 
tet werden, wodurch Teile von Chips zu dark silicon werden können. 


5.5.2 Transientes Verhalten 


Bislang haben wir immer nur den eingeschwungenen Zustand betrachtet. Im Allge- 
meinen muss man zeitlich veränderliche Systeme und die Speicherung mit Wärme- 
kapazitäten betrachten. 


Definition 5.27: Die Wärmekapazität eines Objekts ist definiert als die Menge 
thermischer Energie Ern, die je Differenz A0 der Temperaturen gespeichert werden 
kann: 

Eth 


Crh = — 5.52 
th AO ( ) 


Primär hängt C;n von der Menge und des Art des Materials im Objekt ab: 
Crh = Cp ¥™m (5.53) 


wobei cp die spezifische Warmekapazitat ist und m die Masse. Wir können Gleichung 
(5.53) als Definition der spezifischen Wärme betrachten: 


Definition 5.28: Die spezifische Wärmekapazität c, eines Objekts der Masse m 
ist definiert als 


cp = — (5.54) 


Cp hängt vom Material ab und ist temperaturabhängig, kann aber für kleine Tempe- 
raturdifferenzen als konstant angenommen werden. 

In unserem Kontext ist es häufig sinnvoller, statt der Wärmekapazität pro Massen- 
einheit die Wärmekapazität pro Volumeneinheit zu betrachten. So ist primär i.d.R. 
das Volumen einer Schicht eines Materials bekannt und nur in abgeleiteter Form 
dessen Masse. 
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Definition 5.29: Die volumetrische Wärmekapazität c,, ist definiert als 


Crh 
= — 5.55 
ven (5.55) 
wobei V das Volumen des Objektes ist. 
cy und cp hängen über die spezifische Dichte miteinander zusammen: 
Definition 5.30: Die spezifische Dichte p ist definiert als 
m 
= — 5.56 
P= a (5.56) 
Wenn wir V = m/p in die Definition von c, einsetzen, dann folgt 
Cn C 
cy = Ht = E ey xp (5.57) 


Damit ist es uns möglich, zwischen Tabellen fiir c, und c, umzurechnen (siehe z.B. 
Tabelle 5.1). 

Die Korrespondenz zu elektrischen Schaltungen erlaubt es uns, auch das transiente 
thermische Verhalten zu berechnen. 


Beispiel 5.6: Zur Demonstration der Berechnung des transienten Verhaltens erwei- 
tern wir unser Mikroprozessorbeispiel entsprechend Abb. 5.23 (links). Das resul- 
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Abb. 5.23 Mikroprozessor mit Lüfter: links: thermisches Modell; rechts: transientes Verhalten 


tierende thermische Verhalten ist in Abb. 5.23 (rechts) gezeigt. Das System nähert 
sich einem stabilen Zustand wie ein elektrisches Netzwerk aus Widerständen und 
Kondensatoren. V 


Insgesamt ist es möglich, thermisches Verhalten mittels des äquivalenten elektrischen 
Verhaltens zu modellieren. Tabelle 5.2 zeigt die Äquivalenzen zwischen den Größen. 
Zur Lösung der Netzwerkgleichungen für elektrische Netzwerke können bekannte 
Techniken eingesetzt werden (siehe z.B. Chen et al. [97]). Allerdings gibt es kein 
Äquivalent zu Induktivitäten auf der thermischen Seite. 
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Tabelle 5.2 Äquivalenzen zwischen elektrischen und thermischen Modellen 
Elektrisches Modell Thermisches Modell 
Strom I Thermischer Fluss, Pin =Ò 
„Leistungsfluss” 
Gesamtladung Q= ii I dt Thermische Energie Eth = f P;n dt 
Potential o Temperatur 0 
Spannung=Potentialdifferenz|V = Ab Temperaturdifferenz A0 
Widerstand? R = pei k Thermischer Widerstand Rın = ı z 
Ohmsches Gesetz V=R*I A Temperatur über R;p, A0 = Rin * Pin 
Kapazität C Wärmekapazität Cth 
Ladung auf Kondensator Q=C#xV Energie in Wärmekapazität |E;n = Crp * A0 
Kapazitat eines Objekts” C =p YV Kapazität eines Objekts Cth =CyV 


a: Per ist der spezifische elektrische Widerstand. b, Pq ist die Ladungsdichte. 


Die Äquivalenz zwischen thermischen und elektrischen Modellen wird in Werk- 
zeugen wie beispielsweise HotSpot [499] ausgenutzt. Abb. 5.24 zeigt ein HotSpot- 
Modell eines Chips, der auf einem Wärmeverteiler platziert ist, der wiederum auf 
einem Kühlkörper montiert ist [500]. Skadron et al. [500] betonen, dass innerhalb 
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Abb. 5.24 HotSpot-Modell eines Chips auf einem Wärmeverteiler und einem Kühlkörper 
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eines Chips, eines Warmeverteilers oder eines Kühlkörpers große Temperaturdiffe- 
renzen vorhanden sein können. Daher darf für diese Komponenten keine einheitliche 
Temperatur vorausgesetzt werden. In Abb. 5.24 nehmen wir an, dass der Chip drei 
Mikroarchitektur-Komponenten enthält, von denen jede eine thermische Zone defi- 
niert. 

Der Wärmeverteiler und der Kühlkörper sind je als fünf thermische Zonen model- 
liert. Eine Zone des Warmeverteilers befindet sich unter dem Chip, die vier weiteren 
Zonen modellieren jeweils eine Randzonen. Sie sind trapezförmig. Gepunktete Li- 
nien kennzeichnen Grenzen der Trapeze. Entsprechendes gilt für die fünf Zonen 
des Kühlkörpers. Die verdeckten mittleren Zonen sind aus Darstellungsgründen 
nicht gezeigt. Ansonsten ist jede Zone in Abb. 5.24 als Knoten in dem äquivalenten 
(elektrischen) Netzwerk gezeigt. Die Umgebungstemperatur wird als einheitlich vor- 
ausgesetzt. Reonvection ist der thermische Widerstand zur Umgebung. Er ist mit den 
fünf thermischen Zonen des Kühlkörpers verbunden. Die Verbindung zum Wärme- 
verteiler erfolgt über den Widerstand Rys. Der Wärmeverteiler besteht wiederum aus 
fünf Zonen. Davon ist die mittlere über den Widerstand R,, mit dem Chip verbunden. 
Die Wärmequellen auf dem Chip selbst sind nicht gezeigt. Für jede der Zonen gibt 
es eine thermische Kapazität. Diese modelliert immer die Temperaturdifferenz zur 
Umgebung, dementsprechend sind die Kapazitäten im elektrischen Modell mit der 
Masse verbunden. Außerdem gibt es für jede der Zonen ein Paar von Widerständen, 
die eine thermische Verbindung zu den Nachbarzonen darstellen. 

In ihren Experimenten haben Skadron et al. den Wattch-Simulator (siehe Seite 
287) als Wärmequelle benutzt. Wattch wiederum kann durch Mikroarchitektursimu- 
latoren wie z.B. SimpleScalar getrieben werden. HotSpot enthält Mechanismen zur 
Erzeugung eines Systems aus partiellen Differentialgleichungen für Modelle wie das 
in Abb. 5.24 gezeigte. Diese Gleichungen werden anschließend mit Runge-Kutta- 
Verfahren gelöst. 

Die Ergebnisse von Skadron et al. bestätigen, dass es notwendig ist, verschiede- 
ne thermische Zonen zu betrachten. Der erwartete Einfluss der Leistungsaufnahme 
auf die Temperatur wurde quantitativ nachgewiesen. Verschiedene Techniken zur 
Reduktion der Leistungsaufnahme hatten allerdings nur einen kleinen Einfluss auf 
kritische Temperaturen. Beispielsweise tendieren Registersätze dazu, heiß zu wer- 
den. Eine Reduktion der Leistungsaufnahme für Speicherzugriffe hilft in diesem 
Zusammenhang wenig und kann sogar einen negativen Einfluss haben. 


Beispiel 5.7: Wir betrachten ein MPSoC-System von ST Microelectronics mit 64 
P2012 Kernen [506]. Die thermische Modellierung dieses MPSoCs wurde mit dem 
3D-ICE-Werkzeug [23] vorgenommen. Die Abbildungen 5.25 und 5.26 zeigen re- 
lative Temperaturen für dieses MPSoC-System’. Hohe Temperaturen sind in rot 
angezeigt, niedrige in blau. Das MPSoC-System enthält vier Cluster, jedes mit 16 
Kernen. Jede Ecke des Layouts enthält ein Cluster. Die 16 Prozessoren sind in der 
Mitte der Cluster platziert. Speicher sind unterhalb und oberhalb der Prozessoren an- 


7 Reproduktion dieser Bilder mit freundlicher Genehmigung durch David Atienza (EPFL). Die 
Bilder wurden im Rahmen einer Kooperation zwischen EPFL und ST Microlectronics im Projekt 
PRO3D: Programming for Future 3D Architectures with Many Cores gewonnen. 


5.5 Thermische Modelle 


FPX ~ Blocks 


Abb. 5.25 Ergebnisse der thermischen Simulation eines MPSoCs bei 50% Auslastung 


3D-ICE - ANSYS 


Abb. 5.26 Ergebnisse der thermischen Simulation eines MPSoCs bei 100% Auslastung 
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geordnet. Die Simulation bestätigt, dass die Prozessoren heißer sind als die Speicher. 
Die Abbildung 5.25 entspricht der Situation bei halber Prozessorauslastung. Abbil- 
dung 5.26 spiegelt die Situation bei voller Prozessorauslastung wider. Die größere 
Auslastung in Abb. 5.26 führt zu höheren Temperaturen. Die detaillierte Model- 
lierung des Layouts hatte zur Folge, dass eine Überschätzung der Temperaturen 
vermieden wurde. V 


Die Validierung von Temperaturmodellen erfordert Temperaturmessungen [395]. 


5.6 Verlässlichkeits- und Risikoanalyse 


Als nächstes betrachten wir die Analyse der Verlässlichkeit und möglicher Risiken. 


5.6.1 Aspekte der Verlässlichkeit 


Eingebettete und cyber-physikalische Systeme können (wie andere Produkte auch) 
Schäden an Menschen, Tieren und Material verursachen. Wir haben bereits in Tabelle 
1.2 auf Seite 19 darauf hingewiesen, dass solche Systeme potentiell sicherheitskri- 
tisch sind. Im Allgemeinen werden wir dies berücksichtigen müssen. Dabei ist es 
unmöglich, das Risiko von Schäden komplett zu eliminieren. Wir können nur da- 
für sorgen, dass eine ausreichende Verlässlichkeit gegeben ist. Zur Verlässlichkeit 
gehören die Aspekte der Betriebs- und der Informationssicherheit, die ihrerseits 
wiederum Aspekte wie die Zuverlässigkeit und Vertraulichkeit enthalten. Bezüglich 
dieser Aspekte muss offenbar auch eine Bewertung von Entwürfen erfolgen. 


5.6.2 Informationssicherheit 


Solange auf eingebettete und cyber-physikalische Systeme nicht elektronisch von 
außen zugegriffen werden konnte, galt deren Informationssicherheit nicht als ein 
Problem. Dies hat sich geändert, seit auf Systeme über Kommunikationskanäle 
zugegriffen werden kann. Eine Bewertung dieser Form der Sicherheit muss An- 
griffsszenarien betrachten, wie bereits in Abschnitt 3.8 erwähnt. Dazu zählen u.a. 
Seitenkanal-Angriffe. Wenn ein physischer Zugang möglich ist, dann müssen auch 
physische Angriffe betrachtet werden. 

Darüber hinaus müssen die Beziehungen zwischen Ver- und Entschlüsselungspro- 
tokollen und der erreichbaren Datenrate analysiert werden, da es leicht vorkommen 
kann, dass ressourcenbeschränkte Geräte nicht die erwarteten Ver- und Entschlüsse- 
lungsraten erreichen. 
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5.6.3 Betriebssicherheit 


Betriebssicherheit soll ebenfalls Schäden abwenden. Der bestmögliche Ansatz be- 
steht darin, die Wahrscheinlichkeit von Schäden gering zu halten, sodass sie hoffent- 
lich einige Größenordnungen unter der Wahrscheinlichkeit des Auftretens anderer 
Risiken liegt. 

Eine übliche Minimalanforderung an die Fertigung sicherheitskritischer Systeme 
ist die Einhaltung der Norm ISO 9001. Dieser Standard definiert allgemeine Anfor- 
derungen an ein Qualitätsmanagement. Die Anforderungen gemäß diesem Standard 
beinhalten die folgenden Prinzipien [255]: Kundenfokussierung, Führungsqualitä- 
ten, Engagement der beteiligten Personen, prozessbasierter Ansatz, Verbesserungen, 
evidenzbasierte Entscheidungen und ein Management von Beziehungen. Die ersten 
vier Prinzipien sind mehr oder weniger selbsterklärend. Das Verbesserungsprinzip 
schreibt vor, dass Arbeiten in den Phasen Planung, Realisierung, Überprüfen und 
Handeln ablaufen. In der Planungsphase sollen Ziele, Risiken und Möglichkeiten 
aufgestellt werden. In der Handlungsphase sollen Verbesserungen, sofern notwen- 
dig, umgesetzt werden. 

Für den Entwurf sicherheitskritischer Systeme sind spezifischere Richtlinien ent- 
wickelt und als Standard IEC 61508 publiziert worden [527]. Teil 1 [233] dieses 
Standards definiert Standardtechniken für technische Systeme im Allgemeinen. Teil 
2 [234] spezifiziert Anforderungen für elektrische, elektronische und programmier- 
bare sicherheitskritische Systeme. Anforderungen an die Software werden in Teil 3 
aufgeführt [235]. Die Teile 4 bis 6 enthalten weniger formale Empfehlungen. Diese 
Standards gehen davon aus, dass es nicht möglich ist, technische Systeme zu ent- 
werfen, die zu jeder Zeit die erwarteten Dienste bereitstellen. Die Standards betonen 
die Verwendung von Entwurfsprozessen, welche die Ursachen von ggf. falschen 
Entscheidungen identifizieren können. 

Der Standard IEC 61508 unterscheidet zwischen vier verschiedenen Risikoklas- 
sen, die Safety Integrity Levels (SIL) genannt werden. Für Geräte im Dauerbetrieb 
verlangt der Standard Ausfallraten von 1075 bis 10° pro Stunde für SIL-1, 1076 
bis 1077 pro Stunde für SIL-2, 10°” bis 1078 pro Stunde für SIL-3 und 1078 to 
107° pro Stunde für SIL-4 [581]. SIL-4 entspricht beispielsweise einem Zwischen- 
fall bei 100.000 Systemen mit einer Betriebszeit von jeweils 10.000 Stunden. Diese 
niedrige Ausfallrate ist schwer zu erreichen und setzt typischerweise Redundanz vor- 
aus. Probleme entstehen durch den gegenwärtigen Trend hin zu gemischt-kritischen 
Systemen (Stichwort ,, mixed-criticality”), bei denen Subsysteme verschiedener SIL- 
Klassen beispielsweise auf demselben Mikroprozessor realisiert werden. Eine ge- 
eignete Abschirmung der verschiedenen Klassen voneinander ist i.d.R. schwierig. 

Der Standard IEC 61508 soll in verschiedenen Branchen Anwendung finden. Für 
bestimmte Branchen gibt es aber spezifische Erweiterungen des Standards. Diese 
berücksichtigen u.a. die Zeit, die für menschliche Eingriffe zur Verfügung steht, 
die Möglichkeit, in einen sicheren Modus zu wechseln und die Auswirkungen von 
Fehlfunktionen. In einem Auto gibt es beispielsweise wenig Zeit, um zu reagieren. 
Allerdings können Autos abgebremst und in einem sicheren Modus an einem sicheren 
Ort geparkt werden (mit Ausnahme von z.B. Tunneln). Im Gegensatz dazu steht in 
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einem Flugzeug meist mehr Zeit fiir eine Reaktion zur Verfiigung, aber einige der 
sicherheitskritischen Systeme in einem Flugzeug können nicht einfach abgeschaltet 
werden. 

MISRA-C [397] definiert Regeln, die zu befolgen sind, wenn die Programmier- 
sprache C für sicherheitskritische Systeme benutzt wird. 

Der Standard ISO 26262 [253] wurde speziell für die Automobilindustrie entwi- 
ckelt. Die Standards IEC 62279 und CENELEC 50128 zielen auf die Sicherheit von 
Schienenfahrzeugen [60]. 

Im Bereich der Luftfahrt sollten Systeme die Anforderungen gemäß der Air- 
worthiness Certification Specifications FAR-CS 25.1309 „ Equipment, Systems and 
Installations” und AC-AMC 25.1309 „System design and analysis” [549] erfüllen. 
Für Hardware werden diese Standards ergänzt durch den Standard DO-254 und für 
Software durch den Standard DO-178B (‚Software Considerations in Airborne Sys- 
tems and Equipment Certification”) [474, 163], der in Europa auch ED-12B genannt 
wird. DO-178C ist ein Nachfolge-Standard zum Standard DO-178B. 

Für den Bereich der Fertigung wurde Standard IEC 61511 [237] entwickelt und 
für Kernkraftwerke kommt IEC 61513 [236] zur Anwendung. 

Aus der Betrachtung der SIL-Ebenen geht hervor, dass die Anzahl der erlaubten 
Ausfälle um einige Größenordnungen unter der Ausfallrate von Halbleiterchips liegt. 
Aus diesem Grund hat Kopetz [304] betont, dass das System als Ganzes verlässlicher 
sein muss als irgendeines seiner Teile und dass Sicherheitsanforderungen im Rahmen 
eines Entwurfs nicht nachträglich berücksichtigt werden können, sondern von An- 
fang an betrachtet werden müssen. Offensichtlich müssen Fehlertoleranzmaßnahmen 
benutzt werden. Aufgrund der niedrigen Ausfallrate werden Systeme nicht zu 100 
Prozent testbar sein. Daher muss die Sicherheit mit einer Kombination von Testen 
und logischen Argumenten gezeigt werden. Abstraktion muss genutzt werden, um 
ein System mit Hilfe einer hierarchischen Menge von Verhaltensmodellen erklären 
zu können. Entwurfsfehler und menschliche Fehler müssen betrachtet werden. 

Zur Bewältigung dieser Herausforderungen hat Kopetz zwölf Entwurfsprinzipien 
vorgeschlagen: 


1. Sicherheitsanforderungen müssen als der wesentliche Teil der Spezifikation be- 
trachtet werden, der den gesamten Entwurfsprozess beeinflusst. 

2. Präzise Spezifikationen von Entwurfshypothesen müssen ganz am Anfang vor- 
liegen. Dazu gehören erwartete Fehler und ihre Wahrscheinlichkeit. 

3. Die Eindämmung von Fehlern in bestimmten Regionen (engl. fault containment 
regions (FCRs)) muss betrachtet werden. Fehler in einer Region sollen andere 
Regionen nicht beeinflussen. 

4. Es muss eine konsistente Auffassung von Zeit und Zuständen geben. Ansons- 
ten wird es nicht möglich sein, zwischen ursprünglichen und Folgefehlern zu 
unterscheiden. 

5. Die Interna von Komponenten müssen durch gut definierte Schnittstellen versteckt 
werden. 

6. Es muss sichergestellt werden, dass Komponenten unabhängig voneinander aus- 
fallen. 
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7. Sofern nicht zwei oder mehr Komponenten das Gegenteil behaupten, sollten 
Komponenten sich selbst als korrekt ansehen (Prinzip des Selbstvertrauens). 

8. Fehlertoleranzmaßnahmen müssen so entworfen sein, dass sie keine zusätzlichen 
Schwierigkeiten bei der Erklärung des Systemverhaltens erzeugen. Fehlertole- 
ranzmaßnahmen sollten von der regulären Funktion entkoppelt sein. 

9. Das System muss für die Diagnose entworfen sein. Beispielsweise muss es mög- 
lich sein, vorhandene (aber maskierte) Fehler zu identifizieren. 

10. Das Benutzerinterface muss intuitiv bedienbar sein und trotz Benutzerfehlern 
arbeiten. Die Sicherheit sollte trotz menschlicher Fehler gewährleistet sein. 

11. Alle außergewöhnlichen Vorfälle sollten protokolliert werden. Diese Vorfälle kön- 
nen über die normalen Schnittstellen möglicherweise nicht beobachtet werden. 
Die Protokolle sollten interne Effekte erfassen, die sonst ggf. durch Fehlertole- 
ranzmaßnahmen verdeckt werden könnten. 

12. Es sollte eine Strategie geben, niemals aufzugeben. Eingebettete Systeme müssen 
ununterbrochen ihre Dienste bereitstellen können. Die Erzeugung von Pop-Up 
Fenstern oder das vollständige Abschalten können nicht akzeptiert werden. 


Definition 5.31: Ein System heißt resilient (elastisch), wenn Änderungen an den 
Entwurfsvoraussetzungen im System selbst oder seiner Umgebung für den Benutzer 
nur eine begrenzte Änderung zur Folge haben. 


Ein sich selbst reparierendes System ist in gewissem Umfang resilient. Resilienz 
liegt außerhalb des in diesem Buch behandelten Themenkreises. 


5.6.4 Zuverlässigkeit 


Beim Entwurf verlässlicher Systeme muss auch die Zuverlässigkeit analysiert wer- 
den, d.h. die Wahrscheinlichkeit, dass ein anfänglich korrektes System aufgrund eines 
internen Fehlers seine Dienste nicht mehr anbietet. Es wird erwartet, dass diese Auf- 
gabe künftig wichtiger und schwieriger werden wird, da abnehmende Strukturgrö- 
ßen von Halbleitern deren Zuverlässigkeit reduzieren werden (siehe beispielsweise 
http://variability.org). Auch kann man annehmen, dass sowohl transiente wie auch 
permanente Fehler häufiger auftreten werden. Sinkende Strukturbreiten führen auch 
zu einer erhöhten Variabilität von Schaltungsparametern. Daher werden die Zuver- 
lässigkeitsanalyse und der fehlertolerante Entwurf sehr wichtig werden [407, 179]. 
Diese Analyse hängt eng mit der Modellierung des thermischen Verhaltens zusam- 
men, da hohe Betriebstemperaturen zu einer niedrigeren Lebensdauer der Geräte 
führen. Dieser Zusammenhang wird auf Seite 309 in Form von Gleichung (5.73) 
beschrieben werden. Fehler in Halbleitern können zu Systemausfällen führen. 

Die Begriffe Störung (engl. fault), Ausfall (engl. failure) und die verwandten 
Begriffe Fehler (engl. error) und Dienst (engl. service) wurden von Laprie et al. 
[324, 28] definiert: 


Definition 5.32: ,, Der Dienst, den ein System (in seiner Rolle als Anbieter) liefert, 
ist sein vom Benutzer beobachtbares Verhalten; ... Der erbrachte Dienst ist dabei 
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eine Folge von externen Zuständen des Anbieters. ... Ein fehlerfreier Dienst wird 
geliefert, wenn der Dienst die Systemfunktion implementiert”. 


Definition 5.33: „Ein Dienstausfall, auch einfach als Ausfall (engl. failure) be- 
zeichnet, ist ein Ereignis, das auftritt, wenn der von einem System gelieferte Dienst 
nicht dem fehlerfreien Dienst entspricht. ... Ein Dienstausfall ist ein Übergang von 
fehlerfreiem Dienst hin zu fehlerhaftem Dienst”. 


Definition 5.34: Ein Fehler (engl. error) liegt vor, wenn einer der Systemzustände 
nicht korrekt ist und einen nachfolgenden Dienstausfall verursachen kann. 


Definition 5.35: ,, Die festgestellte oder angenommene Fehlerursache wird auch Stö- 
rung (engl. fault) genannt. Störungen können sowohl innerhalb wie auch außerhalb 
eines Systems auftreten.” 


Einige Störungen verursachen keinen Systemausfall. 

Als Beispiel betrachten wir eine transiente Störung, die ein Bit im Speicher 
kippt. Nach diesem Ereignis ist die Speicherzelle fehlerhaft. Ein Systemausfall 
wird eintreten, wenn ein Systemdienst von diesem Fehler betroffen ist. 

Entsprechend diesen Definitionen verwenden wir den Begriff Ausfallraten, wenn 
wir Systeme betrachten, die nicht die erwartete Funktion zeigen. Wir sprechen immer 
dann von Störungen, wenn wir die zugrunde liegenden Ursachen, die einen Ausfall 
verursachen, betrachten. Es gibt eine große Anzahl möglicher Störungsursachen, 
von denen einige auf die sinkenden Strukturbreiten von Halbleitern zurückzuführen 
sind. Fehler werden im Rest des Buches nicht mehr betrachtet. 

Das Erreichen der Ausfallrate gemäß SIL-4 ist nur machbar, wenn die Bewertung 
des Entwurfs auch eine Analyse der Verlässlichkeit, der erwarteten Lebensdauer und 
verwandter Ziele umfasst. Eine solche Analyse basiert meist auf Ausfallwahrschein- 
lichkeiten. 

Wir betrachten nun die Wahrscheinlichkeitsdichten von Ausfällen genauer. Im 
Folgenden bezeichne x die Zeit bis zum ersten Ausfall eines Systems. x ist eine 
Zufallsvariable. Sei f(x) die Dichtefunktion dieser Zufallsvariablen. 

Eine sehr häufig benutzte Dichtefunktion ist dabei die Exponentialverteilung mit 
der Dichtefunktion f(x) = Ae~**. Bei dieser Dichtefunktion nimmt die Anzahl 
der Systemausfälle mit fortschreitender Zeit immer mehr ab. Dies modelliert ein 
System, bei dem es mit der Zeit immer unwahrscheinlicher wird, dass das System 
noch arbeitet, und ein nicht mehr arbeitendes System kann nicht ausfallen. Die Aus- 
fallrate (implizit bezogen auf die Anzahl noch funktionierender Systeme) ist bei 
dieser Dichtefunktion dagegen konstant (siehe Gleichung (5.68)). Daher kann diese 
Dichtefunktion gut genutzt werden, wenn die (relative) Ausfallrate konstant ist. Aus 
Gründen der einfachen mathematischen Handhabbarkeit benutzt man diese Dichte- 
funktion als Referenz auch dann, wenn sie die exakte Situation nicht widerspiegelt 
oder wenn zunächst eine grobe Übersicht über die Verhältnisse gewünscht wird. 
Darüber hinaus hat diese Dichtefunktion angenehme mathematische Eigenschaften. 
Abb. 5.27 (links) zeigt die Dichtefunktion. 

In vielen Fällen ist man mehr an den Wahrscheinlichkeiten für die Funktionsfä- 
higkeit des Systems interessiert als an den Dichtefunktionen. Allgemein ergibt sich 
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Abb. 5.27 Exponentialverteilung: links: Dichtefunktion; rechts: Wahrscheinlichkeitsverteilung 


die Wahrscheinlichkeit dafür, dass ein System zum Zeitpunkt t fehlerhaft ist, durch 
Integration über die Dichtefunktion. Die so bestimmte Funktion ist die Wahrschein- 
lichkeitsverteilung: 


F(t) = Pr(x < t) (5.58) 
t 
F(t) = i f(x)dx (5.59) 
0 
Für die Exponentialverteilung ergibt sich beispielsweise 
t 
F(t) = / dae**'dx = [e] = 1-e" (5.60) 
0 


Abb. 5.27 (rechts) zeigt die entsprechende Funktion. Mit fortschreitender Zeit nähert 
sich die Wahrscheinlichkeit, dass das System fehlerhaft ist, dem Wert 1. 


Definition 5.36: Unter der Zuverlässigkeit R(t) eines Systems verstehen wir die 
Wahrscheinlichkeit dafür, dass die Zeit bis zum ersten Fehler größer ist als eine Zeit 
f: 


R(t) = Pr(x > t),t > 0 (5.61) 
R(t) = f toa (5.62) 
F(t) + R(t) = [ra + g f(x)dx = 1 (5.63) 
R(t) = 1- F(t) (5.64) 
f(x) = -20 (5.65) 


Für die Exponentialverteilung ergibt sich R(t) = e7% . Abb. 5.28 zeigt diese Funktion. 


Nach einer Zeitt = 1/A beträgt die Wahrscheinlichkeit, dass das System funktioniert, 
noch ca. 37%. 


Definition 5.37: Die Ausfallrate A(t) ist die Wahrscheinlichkeit dafür, dass ein Sys- 
tem im Zeitintervall zwischen t und ¢ + At ausfällt. 
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Abb. 5.28 Zuverlassigkeit fiir 
die Exponentialverteilung \ 


1 u 


Pr(t < x <t+At|x >t) 


N (5.66) 


A(t) = li 
o= pm 


Dabei ist Pr(t < x < t + At|x > t) die bedingte Wahrscheinlichkeit dafür, dass 
das System im Zeitintervall ausfällt, unter der Annahme, dass es zur Zeit t 
noch funktioniert. Für bedingte Wahrscheinlichkeiten gilt die allgemeine Formel 
Pr(A|B) = Pr(AB)/Pr(B), wobei Pr(AB) die Wahrscheinlichkeit des Verbunder- 
eignisses AB ist. In diesem Fall ist Pr(B) die Wahrscheinlichkeit, dass das System 
zur Zeit t noch funktioniert, also R(t). Damit folgt aus Gleichung (5.66): 


PO+hAD=—FU) . fi) 


A(t) = li = 5.67 
A TTS R(t) 22 
Beispielsweise ergibt sich für die Exponentialverteilung®: 
Fe) _Ae® 
Alt) = — = = 5.68 
Var "et (5.68) 


Die Ausfallraten werden häufig in der Einheit FIT (Failure unIT) gemessen. Ein 
FIT entspricht dabei einem erwarteten Ausfall in 10° Stunden. 

Die Ausfallraten vieler echter Systeme sind allerdings nicht konstant. Manche 
folgen der sogenannten „Badewannen“-Kurve (siehe Abb. 5.29). Bei diesem Verhal- 


Abb. 5.29 Badewannenkurve At) 
der Ausfallraten 


1. Phase 


| 
2. Phase | 3. Phase 


ten beginnen wir mit einer zu Anfang größeren Ausfallrate. Diese höhere Rate ist 
eine Folge von gestörten Fertigungsprozessen oder „Frühausfällen”. Die während 
des normalen Betriebs auftretende Rate bleibt dann im Wesentlichen konstant. Am 
Ende der Produktlebenszeit steigt die Rate dann wieder durch Alterungseffekte an. 


8 Dieses Ergebnis legt nahe, dass die Ausfallrate und die Konstante der Exponentialverteilung mit 
demselben Symbol gekennzeichnet werden. 
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Definition 5.38: Unter der mittleren Zeit bis zum Ausfall (engl. Mean Time To 
Failure (MTTF)) verstehen wir die mittlere Zeit bis zu einem Ausfall unter der 


Annahme, dass das System zunächst funktioniert. Diese Zeit ergibt sich als Erwar- 
tungswert der Zufallsvariablen x: 


MTTF = E{x} = f xf(x)dx (5.69) 
0 
Für die Exponentialverteilung ergibt sich beispielsweise 


MTTF = f xae dx (5.70) 
0 


Das Integral können wir mit Hilfe der Produktregel ( f uv’ = uv — [ u’v mitu = x 
und v’ = Ae~** ) bestimmen. Dann ergibt sich aus der Gleichung (5.70): 


MTTF = -[xe |? + f e dx (5.71) 
0 
La 1 1 
a x - __(Q-—]]J = — 5.72 
ale l q1 ] 7 (5.72) 


Bei der Exponentialverteilung ist die mittlere Zeit bis zu einem Ausfall damit gleich 
dem Kehrwert der Ausfallrate. 


Lemma 5.2 (Blacks Gleichung [55, 49]): Es gilt die folgende empirische Beziehung 
zwischen der MTTF und den Betriebstemperaturen: 


AE 


MTTF = — eX? (5.73) 


A : Konstante 

je : Stromdichte 

n : konstant (1..7), umstritten, =2 gemäß Black 
Ea : Aktivierungsenergie (z.B. ~ 0,6 eV) 

k : Boltzmann-Konstante (~ 8,617 * 1075 eV/K) 


0 : Temperatur 


Unabhängig von den Diskussionen um den korrekten Wert von n zeigt diese Glei- 
chung, dass die Temperatur einen exponentiellen Einfluss auf die Lebensdauer des 
Produkts hat. Auch sind die Stromdichten wichtig: um so größer die Stromdichten, 
umso kürzer die Lebensdauer des Produkts. 


Definition 5.39: Unter der mittleren Zeit bis zur Reparatur (engl. Mean Time To 
Repair (MTTR)) verstehen wir die mittlere Zeit bis zur Reparatur eines Ausfalls 
unter der Annahme, dass das System zunächst defekt ist. Die MTTR ist der Erwar- 


310 5 Bewertung und Validierung 


tungswert der Verteilungsfunktion, welche die für eine Reparatur benötigten Zeiten 
beschreibt. 


Definition 5.40: Unter der mittleren Zeit zwischen Fehlern (engl. Mean Time 
Between Failures (MTBF)) verstehen wir die mittlere Zeit zwischen zwei Fehlerer- 
eignissen. 


Die MTBF ergibt sich als Summe der MTTF und der MTTR: 
MTBF = MTTF + MTTR (5.74) 


Abb. 5.30 zeigt eine einfache Sicht dieser Gleichung. Die Zeichnung spiegelt dabei 
nicht wider, dass es sich bei allen Größen um statistische Werte handelt und dass 
daher konkrete Werte für MTBF, MTTF und MTTR abweichen können. Bei vielen 


MTTR 
=P 
verfügbar 
nicht verfügbar > 
-— MTTF >e MTBF ~ d 


= MTBF ~“ = 
Abb. 5.30 Zur Definition von MTTF, MTTR und MTBF 


Systemen werden Reparaturen nicht betrachtet. Auch sollte die MTTR sehr viel klei- 
ner sein als die MT TF. Deswegen werden in vielen Publikationen leider die Begriffe 
MTBF und MTTF weitgehend synonym benutzt. Beispielsweise kann die Lebens- 
dauer einer Festplatte als MTBF angegeben sein, obwohl sie nie repariert werden 
wird. Die Angabe dieser Zahl als MTTF wäre korrekter. Die MTTF beschreibt die 
Verlässlichkeit eines Systems aber immer noch nur sehr grob, insbesondere, wenn 
die Ausfallraten im Lauf der Zeit große Variationen aufweisen. 


Definition 5.41: Unter der Verfügbarkeit (engl. availability) verstehen wir den An- 
teil der Zeit an der Gesamtzeit, zu der wir über ein System verfügen können. 


Die Verfügbarkeit verändert sich im Laufe der Zeit (denken Sie an die Badewannen- 
kurve!). Daher modellieren wir sie als Funktion A(t). Es wird allerdings häufig nur 
die Verfügbarkeit A = lim,_,.. A(t) für große Zeiten betrachtet. Daher definieren wir 


MTTF 


-n 7. 
MTBF we 


A = lim A(t) = 
Too 
Beispielsweise hätte ein System, dass im Mittel 999 Tage benutzt werden kann und 
dann jeweils einen Tag lang repariert wird, eine Verfügbarkeit von A = 0,999. 
Es ist schwierig, tatsächliche Störungsraten zu erhalten. In Abb. 5.31 sind einige 
der wenigen veröffentlichten Ergebnisse zu sehen [546]. Diese Abbildung enthält die 
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Abb. 5.31 Störungsraten von TriQuint Gallium-Arsenid-Halbleitern (mit freundlicher Genehmi- 
gung der TriQuint, Inc., Hillsboro), ©TriQuint 


Ausfallraten für verschiedene Gallium-Arsenid (GaAs)-Halbleiter, wobei der „hei- 
Beste” Transistor bei einer Temperatur von 150°C betrieben wird. Dieses Beispiel 
soll hier zeigen, dass es Geräte gibt, für welche die Annahme konstanter Ausfallraten 
oder eines der Badewannenkurve entsprechenden Verhaltens zu sehr vereinfachend 
sind?. Die Angabe eines einzelnen MTTF-Wertes kann täuschen, vielmehr sollte 
die tatsächliche Verteilung der Ausfälle über der Zeit angegeben werden. In die- 
sem Beispiel sind die Ausfallraten in den ersten 20 Jahren (174.300 Stunden) der 
Produktlebenszeit kleiner als 100 FIT, obwohl die Geräte bei hoher Temperatur be- 
trieben werden. Die Angabe von FIT-Werten ist in der Tat sehr temperaturabhängig. 
Triquint verwendet Temperaturen bis zu 275°C und bekannte Temperaturabhän- 
gigkeiten, um Ausfallraten für eine Zeitdauer, welche die Testdauer übersteigt, zu 
berechnen. Triquint gibt an, dass ihre GaAs-Halbleiter zuverlässiger als gewöhnli- 
che Silizumhalbleiter sind. Ergebnisse von FIT-Tests sind auch für Xilinx-FPGAs 
verfügbar (siehe z.B. [599]). 


5.6.5 Fehlerbaumanalyse, Fehlermöglichkeits- und Einflussanalyse 


Es ist meist nicht machbar, Ausfallraten kompletter Systeme experimentell zu bestim- 
men. Die geforderten Ausfallraten sind zu gering, Ausfälle können auch untragbar 
sein. Es ist nicht möglich, 10° Flugzeuge für 10* Stunden testweise zu fliegen, um 
zu überprüfen, ob eine Ausfallrate von weniger als 107° erreicht wird! Der einzi- 


° Daher wird manchmal die sogenannte logarithmische Normalverteilung betrachtet. 
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ge Ausweg ist die Verwendung einer Kombination der Priifung von Ausfallraten 
von Geräten. Eine formale Ableitung aus diesen Angaben ergibt dann Garantien 
für den zuverlässigen Betrieb des Systems. Ausfälle, die im Entwurf begründet 
liegen, oder von Benutzern verursachte Ausfälle müssen ebenfalls berücksichtigt 
werden. Es ist mittlerweile Standard, Entscheidungsdiagramme zur Berechnung der 
Zuverlässigkeit eines Gesamtsystems aus den Zuverlässigkeitswerten der einzelnen 
Komponenten einzusetzen [261]. 

Schäden sind eine Folge von Risiken (engl. hazards, Möglichkeiten eines Aus- 
falls). Für jeden Schaden, der durch einen Ausfall verursacht werden kann, gibt 
es einen Wert für die Schwere des Schadens (die Kosten) und eine entsprechende 
Wahrscheinlichkeit. Das Risiko kann als Produkt der beiden Werte definiert wer- 
den. Informationen über Schäden, die durch Ausfall von Komponenten verursacht 
werden, können mit verschiedenen Methoden abgeleitet werden [143, 459]: 


e Fehlerbaumanalyse (engl. Fault Tree Analysis (FTA)): Die Fehlerbaumanalyse 
ist eine Top-Down-Methode der Risikoanalyse. Die Analyse beginnt mit einem 
möglichen Schaden und versucht dann, Szenarien zu finden, die zu diesem Scha- 
den führen. FTA basiert auf der Modellierung einer Booleschen Funktion, die 
den Betriebszustand des Systems wiedergibt (funktionierend oder nicht funktio- 
nierend). Bei der FTA werden Symbole für UND- und ODER-Gatter verwendet. 
ODER-Gatter werden verwendet, wenn ein einziges Ereignis einen Ausfall er- 
zeugen kann. UND-Gatter werden verwendet, wenn mehrere Ereignisse oder 
Bedingungen erfüllt sein müssen, damit der Ausfall auftritt. Abbildung 5.32 zeigt 
ein Beispiel!°. 

FTA basiert auf einem strukturellen Modell des Systems, es gibt also die 
Aufteilung des Systems in Komponenten wieder. Die einfachen UND- und 
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Abb. 5.32 Fehlerbaum 


ODER-Gatter können nicht alle Situationen modellieren. Beispielsweise kann 
man mit ihnen keine gemeinsam genutzten Ressourcen modellieren, die nur 


10 Entsprechend dem ANSI/IEEE-Standard 91 verwenden wir die Symbole &, =1 und >1 zur 
Kennzeichnung von UND-, XOR- und ODER-Gattern. 
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in beschränkter Form vorliegen (beispielsweise Energie oder Speicherzellen). 
Markov-Modelle [67] können verwendet werden, um solche Fälle zu modellie- 
ren. Markov-Modelle basieren auf der Darstellung von Zuständen und nicht auf 
der Struktur eines Systems. 

e Fehlerméglichkeits— und Einflussanalyse (engl. Failure Mode and Effect Ana- 
lysis (FMEA)): FMEA beginnt bei den Komponenten und versucht, deren Zu- 
verlässigkeit abzuschätzen. Mit dieser Information wird die Zuverlässigkeit des 
Systems aufgrund der Zuverlässigkeit seiner Bestandteile bestimmt (entsprechend 
einer Bottom-Up-Analyse). Der erste Schritt besteht im Aufstellen einer Tabelle 
der Komponenten, möglicher Störungen, Störungswahrscheinlichkeiten und Aus- 
wirkungen auf das Systemverhalten. Die Risiken für das Gesamtsystem werden 
dann aus dieser Tabelle berechnet. Tabelle 5.3 zeigt ein Beispiel. 


Tabelle 5.3 FMEA-Tabelle 
Komponente | Störung Konsequenzen | Wahrscheinlichkeit | Kritisch? 


Prozessor Metallwanderung | Ausfall 1077 /h ja 


Es sind für beide Ansätze Werkzeuge verfügbar. Sowohl Fehlerbaumanalyse als 
auch FMEA können in sogenannten Safety Cases eingesetzt werden. Dabei muss 
eine unabhängige Instanz davon überzeugt werden, dass ein bestimmter technischer 
Ausrüstungsgegenstand wirklich sicher ist. In diesem Zusammenhang wird häufig 
gefordert, dass der Ausfall einer einzelnen Komponente nicht zu einer Katastrophe 
führen darf. 

Dieses Buch kann hierzu nur einige Hinweise geben. Es gibt reichhaltige Literatur 
zum Entwurf von zuverlässigen Systemen, beispielsweise Veröffentlichungen von 
Huang [224], Zhuo [613] und Pan [445]. Bücher aus diesem Bereich [324, 419, 340, 
513, 181] enthalten weitere Informationen. 


5.7 Simulation 


In diesem Kapitel haben wir uns bislang v.a. mit der Bewertung von Entwürfen be- 
schäftigt. In diesem Abschnitt beginnen wir nunmehr, auch die Validierung von Ent- 
würfen zu betrachten. Validierung ist für jeden Entwurfsvorgang wichtig. Kaum ein 
System würde wie erwartet funktionieren, wäre es nicht während des Entwurfspro- 
zesses validiert worden. Besonders wichtig ist die Validierung für sicherheitskritische 
eingebettete Systeme. Theoretisch ließen sich verifizierte Werkzeuge erstellen, die 
immer korrekte Implementierungen aus einer Spezifikation heraus erstellen. In der 
Praxis funktioniert diese Verifikation von Werkzeugen aber nur in sehr einfachen 
Fällen. Als Folge muss jeder einzelne Entwurf validiert werden. Um die Anzahl der 
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erforderlichen Validierungen eines Entwurfs zu senken, könnten wir versuchen, die 
Validierung erst zum Ende des Entwurfsvorgangs durchzuführen. Leider funktioniert 
dieser Ansatz meist auch nicht, da die Unterschiede zwischen den Abstraktionsebe- 
nen der Spezifikations- und der Implementierungsbeschreibung groß sind. Daher 
sind Validierungen im Entwurfsablauf immer wieder erforderlich. 

Es wäre vorteilhaft, eine einzelne Validierungstechnik für alle Validierungspro- 
bleme anwenden zu können. In der Praxis löst leider keine der verfügbaren Techniken 
alle auftretenden Probleme, daher kommt eine Kombination von Techniken zum Ein- 
satz. Simulationen sind eine sehr weitverbreitete Technik für die Validierung von 
Entwürfen. Eine Simulation besteht aus der Ausführung eines Entwurfsmodells auf 
einer geeigneten Hardware, üblicherweise auf digitalen Standard-Computern. Bei 
diesem Ansatz muss das zu validierende Modell ausführbar sein. Alle in Kapitel 
2 vorgestellten ausführbaren Sprachen können zur Durchführung von Simulationen 
verwendet werden, und zwar auf verschiedenen Abstraktionsebenen (wie auf Sei- 
te 127 beschrieben). Die Abstraktionsebene, auf der simuliert wird, ist stets ein 
Kompromiss zwischen der Simulationsgeschwindigkeit und der Simulationsgenau- 
igkeit. Je schneller die Simulation, desto weniger genau ist sie. 

Bisher haben wir den Begriff „Verhalten“ im Sinne des funktionalen Verhal- 
tens des Systems (also seiner Ein/Ausgabefunktionalität) verwendet. Es gibt auch 
Simulationen von anderen, nicht-funktionalen Aspekten von Entwürfen, etwa des 
thermischen Verhaltens oder der elektromagnetischen Verträglichkeit (engl. Electro- 
Magnetic Compatibility (EMC)) mit anderen elektronischen Geräten. 

Durch die Integration der Physik müssen Simulationsmodelle möglicherweise 
eine große Anzahl physikalischer Effekte beinhalten. Dadurch ist es unmöglich, alle 
zugehörigen Ansätze zur Simulation cyber-physikalischer Systeme in diesem Buch 
zu behandeln. Ein Überblick über Ansätze und Themen der Simulation digitaler 
Systeme ist bei Law [326] zu finden. Es gibt sehr viel weiterführende Literatur zur 
Simulation von Systemen, insbesondere von heterogenen, cyber-physikalischen Sys- 
temen (siehe beispielsweise [363, 126, 442]). Einige Simulatoren sind auf bestimmte 
Anwendungsgebiete spezialisiert, andere sind breiter einsetzbar. 

Für die Validierung cyber-physikalischer Systeme haben Simulationen einige 
schwerwiegende Einschränkungen: 


e Simulationen sind typischerweise viel langsamer als das endgültige System. Wenn 
man also versucht, den Simulator mit der tatsächlichen Umgebung des eingebet- 
teten Systems zu verbinden, würden viele verletzte Zeitbedingungen auftreten. 

e Simulationen in der realen Umgebung können sogar gefährlich sein - wer wür- 
de schon ein Flugzeug mit instabiler, ungetesteter Steuerungssoftware fliegen 
wollen? 

e Viele Anwendungen verwenden sehr große Datenmengen und es ist in der Regel 
unmöglich, in akzeptabler Zeit eine ausreichende Abdeckung dieser Daten durch 
Simulation zu erzielen. Multimediaanwendungen sind typische Vertreter für die- 
sen Effekt. So benötigt etwa die Simulation der Kompression eines Videostroms 
sehr viel Zeit. 

e Die meisten praktisch eingesetzten Systeme sind heutzutage zu komplex, um alle 
möglichen Fälle (Eingaben) simulieren zu können. Daher können Simulationen 
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zwar helfen, Fehler im Entwurf zu entdecken, sie können aber die Fehlerfreiheit 
des Systems nicht garantieren. Es ist nicht möglich, alle Kombinationen von 
Eingaben und internen Zuständen zu simulieren. 


Aufgrund dieser Einschränkungen gewinnt die formale Verifikation zunehmend 
an Bedeutung (siehe Seite 316). Dennoch spielen hochentwickelte Simulations- 
techniken weiterhin eine wichtige Rolle bei der Validierung von Systemen (siehe 
z.B. Braun et al. [66]). Es sind sowohl akademische Lösungen wie gem5 (siehe 
http://gem5.org), SimpleScalar und OpenModelica wie auch kommerzielle Lösun- 
gen wie der Synopsys® Virtualizer™ (siehe http://synopsys.com) verfügbar. Netz- 
werke, wie sie für die Realisierung des Internets der Dinge benötigt werden, können 
mit verschiedenen Werkzeugen simuliert werden, wie z.B. mit OMNET++ (siehe 
https://omnetpp.org/). 


5.8 Rapid Prototyping und Emulation 


Simulationen beruhen auf Modellen, die Annäherungen von realen Systemen dar- 
stellen. Im Allgemeinen gibt es einige Unterschiede zwischen dem realen System 
und dem Modell. Wir können diese Lücke verkleinern, indem wir einige Teile des 
zu entwerfenden Systems präziser als in einem Simulator implementieren (z.B. als 
reale, physische Komponente). 


Definition 5.42: Die Ausführung eines Modells eines Systems, bei der mindestens 
eine Komponente nicht durch eine Simulation auf einem Computer realisiert wird, 
bezeichnen wir als Emulation [384]. 


Nach M°Gregor [384] ist das „Überbrücken der Glaubwürdigkeitslücke nicht der 
einzige Grund für ein steigendes Interesse an Emulation — die obige Definition eines 
Emulationsmodells bleibt auch gültig, wenn sie ins Gegenteil verkehrt wird — ein 
Emulationsmodell ist ein Modell, in dem ein Teil des realen Systems durch ein Mo- 
dell ersetzt wurde. Die Verwendung von Emulationsmodellen, um Regelungssysteme 
unter realistischen Bedingungen zu testen, in denen das ... (reale System) ... durch 
ein Modell ersetzt wird, ist von besonderem Interesse für all jene, die für die Be- 
reitstellung, die Installation und die Inbetriebnahme verschiedenster automatisierter 
Systeme verantwortlich sind.” 

Um die Glaubwürdigkeit noch weiter zu erhöhen, können wir weitere simulierte 
Komponenten durch reale Komponenten ersetzen. Diese Komponenten müssen dabei 
nicht die im endgültigen System eingesetzten sein. Sie können auch selbst wieder 
Näherungen des realen Systems sein, sollten aber präziser als eine Simulation sein. 

Es ist mittlerweile üblich, über „Emulation” eines Computers auf einem anderen 
Computer mit Hilfe von Software zu sprechen. In diesem Zusammenhang fehlt eine 
präzise Definition des Begriffs „Emulation”. Dennoch passt diese Verwendung zu 
unserer Definition, da der emulierte Computer nicht nur simuliert wird. Vielmehr 
wird eine Geschwindigkeit erwartet, die die Simulationsgeschwindigkeit deutlich 
übersteigt. 


316 5 Bewertung und Validierung 


Definition 5.43: Die Ausführung eines Modells eines Systems, in dem keine Kom- 
ponente durch eine computerbasierte Simulation realisiert wird, heißt Rapid Proto- 
typing. Dabei werden alle Bestandteile durch realistische Komponenten dargestellt. 
Einige dieser Komponenten sollten nicht die endgültig verwendeten Komponenten 
sein, da das System ansonsten dem realen System entspräche. 


In vielen Fällen sollten Entwürfe in realistischen Umgebungen getestet werden, bevor 
die endgültige Version produziert wird. Steuergeräte von Autos sind ein hervorra- 
gendes Beispiel hierfür. Diese Systeme sollten von Testfahrern in verschiedenen 
Umgebungen verwendet werden, bevor sie in die Massenproduktion gehen. Daher 
entwirft die Automobilindustrie Prototypen. Diese Prototypen sollten sich größten- 
teils wie die endgültigen Systeme verhalten, sie können dabei aber schwerer sein, 
mehr Energie verbrauchen oder andere Eigenschaften besitzen, die einen Testfahrer 
nicht stören. Der Begriff „Prototyp” kann für das gesamte System aus elektrischen 
und mechanischen Komponenten verwendet werden. Die Unterscheidung zwischen 
Rapid Prototyping und Emulation beginnt aber unscharf zu werden. Rapid Proto- 
typing selbst ist ein umfangreiches Themengebiet, das nicht vollständig in diesem 
Buch behandelt werden kann. 

Prototypen und Emulatoren lassen sich beispielsweise mit Hilfe von FPGAs 
konstruieren. Schaltschränke mit FPGA-Platinen lassen sich für Testfahrten im Kof- 
ferraum eines Autos unterbringen. Dabei ist dieser Ansatz nicht auf die Automobil- 
industrie beschränkt, auch in anderen Fällen werden Prototypen mit FPGAs gebaut. 
Kommerziell verfügbare Emulatoren bestehen aus einer großen Anzahl von FPGAs. 
Wenn solche Emulatoren verwendet werden, können Experimente mit Systemen 
durchgeführt werden, die sich „fast” wie die endgültigen Systeme verhalten. Es ist 
aber bereits bei nicht verteilten Systemen schwierig, Fehler durch Prototypen und 
Emulation zu finden. Bei verteilten Systemen ist die Lage noch einmal komplizierter 
(siehe z.B. [547]). 


5.9 Formale Verifikation 


Die formale Verifikation beschäftigt sich mit formalen mathematischen Beweisen, 
welche die Korrektheit eines Systems zeigen!!. Zur Durchführung einer formalen 
Verifikation wird zuerst ein formales Modell benötigt. Wenn ein Modell erstellt 
wurde, können damit bestimmte Eigenschaften bewiesen werden. Dieser Schritt ist 
nur schwer zu automatisieren und erfordert einigen Aufwand. Wenn ein Modell 
verfügbar ist, können wir versuchen, bestimmte Eigenschaften zu beweisen. 

Die Techniken der formalen Verifikation können anhand der verwendeten Logik 
klassifiziert werden: 


e Aussagen-Logik: In diesem Fall bestehen die Modelle aus Booleschen Glei- 
chungen. Zugehörige Werkzeuge heißen Tautologie-Checker oder Äquivalenz- 


11 Dieser Text zu formaler Verifikation basiert auf einer Gastvorlesung von Tiziana Margaria-Steffen 
an der TU Dortmund. 
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Checker. Sie werden verwendet, um zu entscheiden, ob zwei Darstellungen äqui- 
valent sind oder nicht (es gibt keine unsicheren Fälle). Beispielsweise kann eine 
Darstellung den Gattern einer realen Schaltung entsprechen, während die andere 
der Spezifikation entspricht. Der Beweis der Äquivalenz der beiden Darstellungen 
beweist dann die Korrektheit aller durchgeführter Transformationen (beispiels- 
weise Energie- oder Laufzeitoptimierungen). Tautologie-Checker können häufig 
mit Systemen umgehen, die für eine vollständige simulationsbasierte Validie- 
rung zu groß sind. Der Hauptgrund für die Mächtigkeit von neueren Tautologie- 
Checkern liegt in der Verwendung von binären Entscheidungsdiagrammen (engl. 
Binary Decision Diagrams (BDDs)) [570]. Die Komplexität eines BDD-basier- 
ten Äquivalenz-Checkers für Boolesche Funktionen wächst linear mit der Anzahl 
der Knoten des BDDs. Die Anzahl der Knoten eines BDDs kann zwar exponen- 
tiell mit der Anzahl der Variablen wachsen, aber für viele praktisch relevante 
Funktionen sind BDDs kompakt, sodass ein effizienter Vergleich möglich ist!. 
Im Gegensatz dazu ist die Äquivalenzprüfung von Funktionen in einer DNF- 
Darstellung (also als Summe von Produkten) NP-hart. Auf BDDs basierende 
Äquivalenz-Checker haben daher für diese Anwendung Simulatoren verdrängt, 
sie können mit Schaltungen umgehen, die aus mehreren Millionen Transistoren 
bestehen. 

e Die Prädikatenlogik erster Stufe beinhaltet die Quantifizierung mithilfe der 
Existenz- (4) und All-Quantoren (V). Ein gewisses Maß an Automatisierung für 
die Verifikation durch Prädikatenlogik erster Stufe ist möglich. Da diese Logik 
im Allgemeinen nicht entscheidbar ist, können unsichere Fälle auftreten. 

« Prädikatenlogik höherer Stufe (engl. Higher Order Logic (HOL)): Prädikaten- 
logik höherer Stufe erlaubt es, Funktionen so wie andere Objekte zu manipulieren 
[424]. Bei Verwendung von Logik höherer Ordnung ist die Automatisierung von 
Beweisen schwierig. 


Die Aussagenlogik kann verwendet werden, um zustandslose Logiknetze zu ve- 
rifizieren, sie kann aber nicht direkt endliche Automaten modellieren. Für kurze 
Eingabefolgen kann es ausreichen, die Rückkopplung des Automaten aufzutrennen 
und im Endeffekt mehrere Kopien dieses Automaten zu betrachten, von denen je- 
de die Auswirkung eines Eingabemusters wiedergibt. Diese Methode ist aber nicht 
sinnvoll auf längere Eingabefolgen anwendbar. 

Solche Folgen können mittels Modellüberprüfung (engl. model checking) ver- 
arbeitet werden. Beim model checking erhält das Verifikationswerkzeug zwei Ein- 
gaben: 


1. Ein Modell des zu verifizierenden Systems und 
2. die zu überprüfenden Eigenschaften. 


Zustände können mit 3 und V quantisiert werden, Zahlen jedoch nicht. Verifikati- 
onswerkzeuge können die Eigenschaften beweisen oder widerlegen. Für letzteren 
Fall können sie ein Gegenbeispiel angeben. Model checking lässt sich leichter als 


12 Die Multiplikation ist eine prominente Ausnahme [285]. 
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Logik erster Ordnung automatisieren. Es wurde zum ersten Mal im Jahr 1987 un- 
ter Verwendung binärer Entscheidungsdiagramme (BDDs) implementiert. Model 
checking war dazu in der Lage, verschiedene Fehler in der Spezifikation des future 
bus-Protokolls zu entdecken [104]. UPPAAL ist ein sehr viel genutztes Werkzeug 
für das model checking'?. 

Diese Technik könnte beispielsweise genutzt werden, um Eigenschaften des Mo- 
dells der Zugbewegungen aus Abb. 2.52 zu beweisen (siehe Seite 91). Es sollte 
möglich sein, das Petrinetz in ein StateChart umzuwandeln und dann nachzuweisen, 
dass die Anzahl der Züge zwischen Köln und Paris in der Tat konstant ist, wodurch 
unsere Diskussion von Ortsinvarianten von Petrinetzen von Seite 89 bestätigt würde. 

Weitere Techniken werden von Haubelt und Teich beschrieben [207]. 


5.10 Aufgaben 


Die folgenden Aufgaben sollten entweder zu Hause oder während einer Anwesen- 
heitsphase nach dem flipped classroom-Konzept [376] bearbeitet werden: 


5.1: Wir betrachten ein Anwendungsbeispiel der Pareto-Optimalität auf der Basis 
von Ergebnissen der Task Concurrency Management (TCM) Werkzeuge des IMEC- 
Forschungszentrums. In diesem Beispiel werden verschiedene Optionen betrach- 
tet, mit denen ein MPEG-4-Abspielprogramm auf Mehrkern-Prozessoren verteilt 
werden können [595]. Wong et al. nehmen dabei an, dass eine Kombination von 
StrongARM-Prozessoren und speziellen Hardwarebeschleunigern benutzt werden 
soll. Vier Entwürfe erfüllen die Zeitbeschränkung von 30 ms (siehe Tabelle 5.4). Für 


Tabelle 5.4 Prozessorkonfigurationen 


Prozessorkonfiguration 1/2);3]4 
Anzahl schneller Prozessoren | 6 | 5 | 4 | 3 
Anzahl langsamer Prozessoren | 0 | 3 | 5 | 7 
Anzahl Prozessoren insgesamt | 6 | 8 | 9 | 10 


die Kombinationen 1 und 4 erfüllt nur eine Abbildung von Tasks auf Prozessoren die 
Zeitbeschränkung. Für die Kombinationen 2 und 3 gibt es verschiedene zulässige 
Task/Prozessorzuordnungen. Diese werden in Abb. 5.33 gezeigt. Welche Fläche 
im Raum der Zielkriterien ist durch mindestens eine Task/Prozessorzuordnung der 
Konfiguration 3 dominiert? Gibt es eine Task/Prozessorzuordnung der Konfigura- 
tion 2, die nicht durch eine Task/Prozessorzuordnung der Konfiguration 3 domi- 
niert wird? Welche Fläche im Raum der Zielkriterien dominiert mindestens eine 
Task/Prozessorzuordnung der Konfiguration 3? 


13 Siehe http://www.uppaal.org für die akademische und http://www.uppaal.com für die kommer- 
zielle Version. 
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Abb. 5.33 Pareto-Punkte für Konfigurationen 2 und 3 


5.2: Welche Anforderungen gibt es für die Berechnung der geschätzten größtmögli- 
chen Ausführungszeit (WCETgsr)? 


5.3: Wir betrachten abstrakte Cachezustände bei rekonvergenten Programmpfaden. 
Abb. 5.34 zeigt die abstrakten Zustände vor der Verschmelzung. Nunmehr betrachten 


{e} | ff {a} | {9} 


~ 
7 


dd p {c.f} | {9} 


Abb. 5.34 Abstrakte Cachezustände 


wir die abstrakten Zustände nach der Verschmelzung. Welcher neue Zustand ergibt 
sich aufgrund einer must-Analyse? Welcher neue Zustand ergibt sich aufgrund einer 
may-Analyse? 


5.4: Betrachten Sie einen eingehenden Ereignisstrom mit Bursts! Der Strom ist 
periodisch mit einer Periode von T. Zu Beginn einer jeder Periode gehen zwei 
Ereignisse im Abstand von d Zeiteinheiten ein. Entwickeln Sie Ankunftskurven für 
diesen Strom! Die entstehenden Graphen sollen die Zeiten von 0 bis 3*7 darstellen. 


5.5: Angenommen, wir haben einen Prozessor mit einer maximalen Performanz von 
b. 


1. Wie sehen die service curves aus, wenn die Performanz aufgrund von Cachekon- 
flikten auf b’ absinken kann? 

2. Wie ändern sich die service curves, wenn ein Zeitgeber das ausgeführte Programm 
alle 100 ms unterbricht und wenn die Unterbrechung jeweils 10 ms andauert? Wir 
nehmen an, dass es keine Cachekonflikte gibt. 
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3. Wie ändern sich die service curves, wenn Sie Cachekonflikte wie unter (1.) und 
Unterbrechungen wie unter (2.) betrachten? 


Die erzeugten Graphen sollten die Zeiten von 0 bis 300 ms darstellen. 


5.6: Stellen Sie sich vor, wir wollen Bernstein sammeln. Allerdings gibt es das Ri- 
siko, dass wir stattdessen weißen Phosphor sammeln. Angenommen, wir haben 50 
Objekte gesammelt und wir lassen sie zunächst alle im Wasser, um das Risiko eines 
Feuers zu vermeiden. Wir klassifizieren 30 Objekte als Bernstein und 20 als weißen 
Phosphor. Tatsächlich sind zwei der Objekte, die wir für Bernstein halten, weißer 
Phosphor und acht Objekte, die wir für Phosphor halten, sind tatsächlich Bernstein. 
Berechnen Sie die Genauigkeit (engl. precision), Sensitivität (engl. sensivity), Kor- 
rektklassifikationsrate (engl. accuracy) und Spezifizität (engl. specificity) unserer 
Klassifikation! 


5.7: Angenommen, Sie wollen die Leistungsaufnahme Ihres Mobiltelefons mit ei- 
nem Shunt-Widerstand messen. Die folgenden Werte sind für die Bestimmung der 
Leistungsaufnahme zum Zeitpunkt t relevant: Widerstand: 0,47 Ohm, Spannung des 
Netzteils: 5,1 V, Spannung über dem Widerstand: 0,23 V. Wie groß ist die Leistungs- 
aufnahme zur Zeit t? 


5.8: Gegeben sei eine Kupferplatte der Fläche A=10 cm? und Dicke 5 mm. Wie viel 
thermische Leistung fließt zwischen den Enden der Platte, wenn die Temperaturdif- 
ferenz zwischen den beiden Seiten 10 °C beträgt? 


5.9: Wir betrachten eine Menge von Plattenlaufwerken, von denen die Hälfte nach 
5000 Betriebsstunden ausgefallen ist. Wir nehmen an, dass die Ausfälle einer expo- 
nentiellen Verteilung folgen. Wie groß ist das A dieser Verteilung? 
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Kapitel 6 A 
Abbildung von Anwendungen EECA 


Ein sehr wichtiger Schritt im Entwurfsprozess ist die Abbildung von Anwendungen 
auf verfügbare Hardware-Plattformen. Dazu müssen wir entscheiden, auf welchem 
Prozessor Anwendungen (oder Teile davon) ausgeführt werden und wie sie zeitlich 
eingeplant werden. Dabei sollten so viele Entscheidungen wie möglich zur Entwurfs- 
zeit getroffen werden, um Garantien für das Zeitverhalten geben zu können. Dies 
ist mit geeigneten Scheduling-Verfahren möglich. In diesem Kapitel geben wir eine 
Übersicht über statische Verfahren und wir klassifizieren diese anhand der Triplet- 
Notation von Pinedo und anderen. Wir starten dazu mit einer Vorstellung von klassi- 
schen Verfahren für Einzelprozessoren sowohl für aperiodische wie auch für periodi- 
sche Tasksysteme, wobei wir u.a. die bekannten Verfahren Earliest Deadline First 
(EDF) und Rate Monotonic Scheduling (RMS) vorstellen. Nach einem Hinweis auf 
die Benutzung von bin-packing-Algorithmen für homogene Mehrprozessor-Systeme 
gehen wir auf die Betrachtung von heterogenen Mehrprozessor-Systemen über. Wir 
stellen jeweils Algorithmen für unabhängige und abhängige Jobs vor. Dabei zeigt 
sich, dass für abhängige Jobs v.a. heuristische Verfahren in Frage kommen. Das 
Kapitel schließt mit Hinweisen auf dynamische Verfahren. 


6.1 Problemdefinition 
6.1.1 Präzisierung des Entwurfsproblems 


Die skizzierte Abbildung auf Hardware-Plattformen ist auch Teil des vereinfachten 
Entwurfsflusses in Abb. 6.1. 

Die in Frage kommenden Scheduling-Verfahren sollten es möglich machen, ein 
System mit einer bestimmten Kombination von Anwendungen zu betreiben. So er- 
warten wir beispielsweise von einem Mobiltelefon, dass wir telefonieren können, 
während der Bluetooth-Stack gleichzeitig die Audiosignale an einen Kopfhörer über- 
trägt und wir Informationen im Adressbuch nachschlagen. Parallel dazu könnte auch 
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Abb. 6.1 Vereinfachter Entwurfsfluss 


noch eine Dateiübertragung oder sogar eine Videoverbindung aktiv sein. Wir müssen 
sicherstellen, dass all diese Anwendungen zusammen verwendet werden können und 
dass dabei die Echtzeitbedingungen eingehalten werden (keine Tonstörungen beim 
Telefonieren). Dies lässt sich durch eine Analyse der Anwendungsfälle erreichen. 

Eine besondere Eigenschaft von eingebetteten und cyber-physikalischen Syste- 
men ist, dass Hardware und Software gleichermaßen während des Entwurfs berück- 
sichtigt werden müssen. Daher wird diese Art des Entwurfs auch als Hardware/Soft- 
ware-Codesign bezeichnet. Das generelle Ziel ist hier, die richtige Kombination aus 
Hardware und Software zu finden, damit das effizienteste Produkt entsteht, das der 
Spezifikation genügt. Deshalb können eingebettete Systeme nicht durch ein Synthe- 
severfahren entworfen werden, welches nur eine Verhaltensbeschreibung betrachtet, 
vielmehr müssen die vorhandenen Komponenten mit in das Verfahren einbezogen 
werden. Es gibt noch weitere Gründe für diese Beschränkung: um die stetig steigen- 
de Komplexität eingebetteter Systeme beherrschen zu können und immer kürzere 
Entwicklungszyklen zu realisieren, ist Wiederverwendung ein unerlässliches Grund- 
prinzip. Dieser Ansatz führte zum Begriff plattformbasierter Entwurf: 

„Eine Plattform ist eine Familie von Architekturen, die eine Menge von Bedingun- 
gen erfüllen, welche eingeführt wurden, um die Wiederverwendung von Hardware- 
und Softwarekomponenten zu ermöglichen. Dabei reicht eine Hardwareplattform 
alleine nicht aus. Ein schneller, zuverlässiger, ableitender! Entwurf erfordert die 
Verwendung einer Anwendungsprogrammierschnittstelle (API) für die Plattform, 
um die Plattform in Richtung der Anwendungssoftware erweitern zu können. Allge- 
mein ist eine Plattform eine Abstraktionsebene, die viele der möglichen Details einer 
unteren Ebene verdeckt. Plattformbasierter Entwurf ist eine Kompromisslösung: im 
top-down Entwurfsfluss bilden Entwickler eine Instanz der oberen Plattform auf 
eine Instanz der unteren Plattform ab und propagieren dabei die Entwurfsbeschrän- 
kungen” [476]. Die Abbildung ist ein iterativer Vorgang, in dem Werkzeuge zur 
Performanz-Bewertung die jeweils nächste durchzuführende Aufgabe bestimmen. 

In diesem Buch liegt der Schwerpunkt auf dem Entwurf eingebetteter Systeme 
basierend auf vorhandenen Ausführungsplattformen. Dies spiegelt die Tatsache wi- 
der, dass viele moderne Systeme auf bereits existierenden Plattformen aufbauen. 


1 Gemeint ist: aus der Spezifikation ableitend. 
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Von den in diesem Buch beschriebenen Techniken abweichende Methoden miis- 
sen in Fällen eingesetzt werden, in denen zusätzlich auch die Ausführungsplattform 
entworfen werden soll. Aufgrund unseres Schwerpunktes betrachten wir die Ab- 
bildung von Anwendungen auf Ausführungsplattformen als das maßgebliche 
Entwurfsproblem. 

Auch für den plattformbasierten Entwurf kann es eine Anzahl von Entwurfsop- 
tionen geben. So könnten wir zwischen verschiedenen Varianten einer Plattform aus- 
wählen, bei denen jede Variante über eine unterschiedliche Anzahl an Prozessoren, 
unterschiedliche Geschwindigkeiten oder eine andere Kommunikationsarchitektur 
verfügt. Zudem könnte es verschiedene anwendbare Scheduling-Verfahren geben. 
Daher müssen die jeweils passenden Optionen ausgewählt werden. 

Damit kommen wir zur folgenden Definition des Abbildungsproblems [535]: 
Gegeben sind: 


e eine Menge von Anwendungen, 
e Anwendungsfalle, welche die Verwendung der Anwendungen beschreiben und 
e eine Menge an möglichen Architekturen: 


— (möglicherweise heterogene) Prozessoren, 
— (möglicherweise heterogene) Kommunikationsarchitekturen und 
— verschiedene mögliche Scheduling-Verfahren. 


Finde nun: 


e Eine Abbildung von Anwendungen auf Prozessoren, 
e dazu passende Scheduling-Verfahren (wenn nicht festgelegt) und 
e eine Zielarchitektur (wenn nicht vorab festgelegt). 


Zielsetzungen sind dabei: 


e Einhalten von Deadlines und/oder Maximierung der Performanz sowie 
e Minimierung der Kosten, des Energieverbrauchs und möglicherweise weitere 
Ziele. 


Die Erforschung der möglichen Architekturoptionen wird als Erkundung des Ent- 
wurfsraumes (engl. Design Space Exploration (DSE)) bezeichnet. Dabei kann eine 
vollständig festgelegte Plattformarchitektur als Spezialfall betrachtet werden. 

Ein Beispiel ist der Entwurf eines AUTOSAR-basierten automotiven Systems: 
In AUTOSAR [27] kommen eine Anzahl heterogener Ausführungseinheiten oder 
Steuergeräte (engl. Embedded Control Units (ECUs)) und eine Anzahl von Soft- 
warekomponenten zum Einsatz. Die Frage, die sich nun stellt, lautet: Wie können 
die einzelnen Softwarekomponenten auf die Steuergeräte abgebildet werden, sodass 
alle Echtzeitbedingungen eingehalten werden? Dabei möchten wir eine minimale 
Anzahl an Steuergeräten verwenden. 

Bei eingebetteten Systemen können wir annehmen, dass die Anwendungen eine 
Anzahl von Tasks enthalten, die wiederholt ausführungsbereit werden. Mit diesen 
Tasks können wir den auszuführenden Softwarecode assoziieren. Beispielsweise 
kann es notwendig sein, einen bestimmten Code genau einmal für jeden Eingabewert 
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auszuführen. Jede einzelne Task bezeichnen wir als t; und die Menge aller Tasks als 
T = {T,..., Tp}. 

Definition 6.1: Jede Ausführung einer Task heißt ein Job (siehe auch Definition 
4.4). Zu jeder Task 7; gehört eine Menge J(T;) von Jobs. Aufgrund der wiederholten 
Ausführungen ist die Menge der Jobs von Task t; möglicherweise nicht endlich. 


Definition 6.2: Tasks 7;, die alle T Zeiteinheiten ausführungsbereit werden, heißen 
periodische Tasks mit der Periode T. 


Definition 6.3: Eine Task 7; heißt sporadisch, wenn es eine untere Schranke für den 
Abstand der Zeitpunkte gibt, zu denen die Task ausführungsbereit wird. Für jede 
sporadische Task t; nennen wir diese Schranke auch 7;. 


Diese Schranke ist wichtig: ohne eine solche Schranke könnten die Ankunftskurven 
für jedes A unbeschränkt werden. Es wäre dann nicht möglich, für eine beschränkte 
Menge an Ressourcen ein Schedule zu finden. 


Definition 6.4: Tasks, die weder periodisch noch sporadisch sind, heißen aperi- 
odisch. 


Das Konzept der Hyperperioden ist für periodische und sporadische Task-Systeme 
nützlich: 


Definition 6.5: Sei t ein periodisches oder sporadisches Task-System. Seine Hy- 
perperiode ist definiert als das kleinste gemeinsame Vielfache (KGV) der Perioden 
der einzelnen Tasks. 


Wenn für eine Menge von Tasks für eine Hyperperiode ein Schedule existiert, dann 
existiert es aufgrund der wiederholten identischen Scheduling-Aufgaben auch für 
alle Hyperperioden. 


6.1.2 Typen von Scheduling-Problemen 


Im verbleibenden Teil dieses Kapitels wird die nachfolgende Notation für Jobs 
benutzt: Sei J = {J;} eine Menge von Jobs. Sei ferner (siehe Abb. 6.2): 


e ri der Zeitpunkt, an dem J; ausführungsbereit wird (engl. release time), 

e C; die größtmögliche Ausführungszeit (engl. Worst Case Execution Time 
(WCET)) von J;, 

e di die (absolute) Deadline von J,;, 

e Di die relative Deadline, d.h. die Zeit zwischen r; und der Zeit, zu der J; seine 
Ausführung beendet haben soll (D; = di - ri), 

« l; der Schlupf (engl. laxity oder slack), definiert als 


ent (6.1) 


(wenn l; = 0 ist, dann muss J; sofort ausgeführt werden, nachdem er ausfüh- 
rungsbereit ist), 
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e s; die Zeit, zu der die Ausführung von J; startet, 
e fi die Zeit, zu der die Ausführung von J; beendet wird (engl. finishing time). 


In Abbildungen wie in Abb. 6.2 bedeuten nach oben zeigende Pfeile die Zeit, zu 
der Jobs ausführungsbereit werden und nach unten zeigende Pfeile die Deadline der 
Jobs. 


Di Ci 
nn — — qu“ 
Ci li 
ausführen 
G d; a N fi di 


Abb. 6.2 Notation für Jobs 


Klassifizieren werden wir Scheduling-Probleme im Folgenden gemäß der Triplet- 
Notation, die von Pinedo vorgestellt wurde [455] und die auf einer Notation basiert, 
die ursprünglich von Graham, Lawler, Lenstra und Kan vorgeschlagen wurde [190]. 
Diese Notation nutzt das folgende Triplet: 


(a|Bly). (6.2) 


Das a-Feld 


Das a-Feld beschreibt die Maschine, auf der Jobs ausgeführt werden sollen. Einfache 
Scheduling-Algorithmen behandeln den Fall eines einzelnen Prozessors, wohingegen 
komplexe Algorithmen auch Systeme mit mehreren Prozessoren behandeln können. 
In diesem Buch betrachten wir die folgenden Werte für das a-Feld: 


« Ein Wert von 1 zeigt einen einzelnen Prozessor an. 

e Ein Wert Pm zeigt an, dass es m Prozessoren gibt, die parallel benutzt werden 
können. Jeder Job kann mit derselben Ausführungszeit auf jedem der m Prozesso- 
ren ausgeführt werden. Man nennt die Prozessoren in diesem Fall identisch oder 
homogen. Das -Feld kann benutzt werden, um die möglichen Zuordnungen von 
Jobs zu Prozessoren einzuschränken. 

« Ein Wert von Om bezeichnet parallele Prozessoren mit unterschiedlichen Perfor- 
manzen (Rechenleistungen). Die Performanz jedes Prozessors wird durch einen 
Skalierungsfaktor relativ zum langsamsten der Prozessoren angegeben. Alle Ska- 
lierungsfaktoren zusammen werden durch einen Vektor (s1, .., Sm) ausgedrückt, 
wobei sk der Skalierungsfaktor für Prozessor rk ist. In diesem Fall heißen die 
Prozessoren uniform. Das uniforme Prozessormodell ist stark vereinfacht, wir 
werden uns kaum darauf beziehen. 

« Ein Wert von Rm zeigt an, dass es m Prozessoren mit unterschiedlichen Ausfüh- 
rungszeiten gibt. Die Ausführungszeit von Job oder Task i auf Prozessor k ist 
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C;,x. Diese Prozessoren heißen heterogen. Heterogene Prozessoren können für 
bestimmte Zielkriterien optimiert sein, beispielsweise für einen geringen Ener- 
gieverbrauch oder für eine hohe Rechenleistung. Daher sind heterogene Prozes- 
soren für eingebettete Systeme sehr wichtig. Als Sonderfall können auch spezielle 
Hardware-Beschleuniger modelliert werden. 


Das a-Feld besteht immer nur aus einer Komponente. 


Das ß-Feld 


Das ß-Feld beschreibt Beschränkungen für die Verarbeitung. Das -Feld kann meh- 
rere Komponenten enthalten. In diesem Buch betrachten wir die folgenden Werte 
für dieses Feld: 


Ein Eintrag r; bezeichnet existierende release times, d.h. Zeiten, an denen Job i 
ausführungsbereit wird. 

Ein Eintrag prmp bedeutet, dass Verdrängung (engl. preemption) erlaubt ist. 

Wenn dieser Eintrag fehlt, wird angenommen, dass keine Verdrängung möglich 
ist. Nicht verdrängendes Scheduling basiert auf der Annahme, dass Jobs ausge- 
führt werden, bis sie beendet sind. Daher kann die Reaktionszeit? für externe 
Ereignisse sehr groß sein, wenn manche Jobs eine lange Ausführungszeit haben. 
Verdrängende Scheduler müssen benutzt werden, wenn manche Jobs eine lange 
Ausführungszeit haben oder wenn die Antwortzeit für externe Ereignisse sehr 
kurz sein muss. Allerdings kann preemption zu unvorhersehbaren Ausführungs- 
zeiten für die verdrängten Jobs führen. Daher kann es erforderlich sein, Ver- 
drängungen zu beschränken, damit Jobs mit harten Deadlines ihre Zeitschranke 
einhalten. 

Ein anderer möglicher Eintrag bezieht sich auf die Art der Zeitschranken. Wir 
unterscheiden zwischen weichen und harten Zeitschranken, siehe Definition 1.8 
auf Seite 11. 

Scheduling für weiche Zeitschranken basiert häufig auf Erweiterungen von 
Standard-Betriebssystemen. Wir werden solche Systeme in unserem Buch nicht 
weiter betrachten. Daher ist unsere Standardannahme, dass wir harte Zeitschran- 
ken haben. 

Einträge periodic und sporadic können beschreiben, dass wir es mit periodischen 
bzw. sporadischen Task-Systemen zu tun haben. 

Ein Eintrag prec drückt aus, dass Präzedenzrelationen (engl. precedence cons- 
traints) existieren. Präzedenzrelationen bewirken, dass Jobs gemäß einer be- 
stimmten partiellen Ordnung ausgeführt werden müssen. Eine Ursache dafür 
kann in der Kommunikation zwischen Jobs liegen. Für eingebettete Systeme sind 
Präzedenzrelationen eher die Regel als eine Ausnahme. 

Für sporadische und periodische Tasks unterscheiden wir Scheduling-Probleme 
häufig anhand der Deadlines: 


2 Das ist die Zeit vom Auftreten des externen Ereignisses bis zum Abschluss der benötigten 
Reaktion. 
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Wir sprechen von Tasks mit impliziten Deadlines (engl. implicit deadline tasks), 
wenn D; = T; für alle i gilt. Wir nennen diese Tasks dann auch Liu-and-Layland 
(L & L) tasks [348]. Dieser Fall wird durch einen Eintrag D; = T; gekennzeichnet. 
Wir sprechen von Tasks mit beschränkten Deadlines (engl. constrained deadline 
tasks) wenn D; < T; für alle i gilt. 

Wenn es hinsichtlich der Deadlines keine Beschränkungen gibt, sprechen wir von 
Mengen von Tasks mit beliebigen Deadlines (engl. arbitrary deadline tasks). 
Diese Information hinsichtlich der Deadlines wird ebenfalls durch eine entspre- 
chende Komponente im -Feld kenntlich gemacht. 

Wir können dieses Feld auch benutzen, um zu beschreiben, welche Form von 
Scheduling benutzt werden soll. Beispielsweise können wir Komponenten fixed- 
Job-prio bzw. fixed-task-prio verwenden, um auszudrücken, dass Jobs bzw. Tasks 
eine feste Priorität haben sollen. 

Außerdem könnten wir zwischen statischem und dynamischem Scheduling unter- 
scheiden. Dynamische Scheduler treffen Entscheidungen zur Laufzeit. Sie sind 
sehr flexibel, aber sie erzeugen zur Laufzeit Overhead. Außerdem sind ihnen glo- 
bale Zusammenhänge wie der Ressourcenbedarf und Reihenfolgebeschränkun- 
gen in der Regel nicht bekannt. Bei eingebetteten Systemen sind solche globalen 
Zusammenhänge meist verfügbar und sie sollten ausgenutzt werden. 

Statische Schedules nutzen Entscheidungen zur Entwurfszeit. Sie basieren darauf, 
dass die Startzeiten von Jobs vorab geplant werden und dass Tabellen mit den 
Startzeiten einem einfachen Dispatcher mitgeteilt werden. Der Dispatcher trifft 
keine Entscheidungen, sondern startet lediglich die Jobs entsprechend der Zeiten, 
die in der Tabelle eingetragen sind. Der Dispatcher kann durch einen Zeitgeber 
getriggert werden, der ihn die Tabelle analysieren lässt. Systeme, die vollständig 
durch einen Zeitgeber kontrolliert werden, heißen vollständig zeitgesteuert (engl. 
entirely time triggered (TT systems)). Derartige Systeme werden im Buch von 
Kopetz [304] detailliert vorgestellt. 
„In einem vollständig zeitge- 
steuerten System wird der zeit- 
liche Ablauf aller Tasks vor- 10 | starte tl | 12 

ab durch off-line Werkzeuge ge- Eu ee A ©) 
plant. Dieser zeitliche Ablauf 38 | starte 72 
wird gespeichert in einer Task- 47 | sende M3 
Descriptor List (TDL), die den 
zyklischen Ablauf aller Aktivi- 
täten ... enthält (siehe Abb. 6.3). 
Der Ablauf beachtet Reihenfol- 
gebedingungen und den gegenseitigen Ausschluss zwischen Tasks, sodass eine 
explizite Koordination der Tasks durch das Betriebssystem zur Laufzeit nicht 
notwendig ist. Der Dispatcher wird durch synchronisierte Taktsignale aktiviert. 
Er sieht sich die TDL an und fiihrt dann die Aktion aus, die fiir diesen Zeitpunkt 
geplant ist”. 

Der Hauptvorteil des statischen Schedulings ist, dass man einfach prüfen kann, 
ob die Zeitschranken eingehalten sind. „Die Vorhersagbarkeit des Systemver- 


Zeit Aktion |WCET 


20 Dispatcher 


Abb. 6.3 TDL in einem zeitgesteuerten System 
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haltens ist der wichtigste Aspekt, um Zeitschranken in harten Echtzeitsystemen 
einzuhalten; Scheduling vor der Ausführungszeit ist häufig die einzige praktische 
Methode, um in einem komplexen System Vorhersagbarkeit zu bieten” [604]. Der 
Hauptnachteil ist, dass die Antwortzeit auf Ereignisse recht schlecht sein kann. 


e Scheduling-Algorithmen für Mehrprozessor-Systeme können entweder lokal auf 
einem Prozessor ausgeführt werden oder unter einer Menge von Prozessoren 
aufgeteilt werden. Wir können daher zwischen zentralisiertem und verteiltem 
Scheduling unterscheiden. Diese Unterscheidung könnte auch im $-Feld ausge- 
drückt werden. 


Das y-Feld 


Das y-Feld beschreibt die Zielfunktion. In diesem Buch betrachten wir die folgenden 
Werte für dieses Feld: 


« Ein Eintrag Lmax bedeutet, dass die maximale Verspätung zu minimieren ist. 


Definition 6.6: Die maximale Verspätung (engl. maximum lateness) ist defi- 
niert als die Differenz zwischen dem Berechnungsende f; und der Deadline di, 
maximiert über alle Tasks i. 


Die maximale Verspätung ist negativ, wenn alle Tasks ihre Berechnungen vor 
ihrer Deadline beenden. 

e Ein Eintrag M Smax bezeichnet die Minimierung des Makespan, d.h. der Zeit, zu 
der die letzte Ausführung beendet ist. 


Definition 6.7: Der Makespan ist definiert als? 
M Smax = max;(fi) (6.3) 


e Zusätzlich zu den Einträgen, die Pinedo betrachtet, sind auch weitere Einträge für 
eingebettete Systeme relevant. Beispielsweise möchten wir vielleicht den Ener- 
gieverbrauch minimieren oder wir möchten Tradeoffs (also z.B. Pareto-Kurven) 
zwischen verschiedenen Bewertungskriterien betrachten. 


Es gibt eine riesige Menge an Scheduling-Algorithmen und eine umfassende Be- 
handlung existierender Algorithmen wäre selbst dann nicht möglich, wenn ein voll- 
ständiges Buch oder ein ganzer Kurs zur Verfügung stünden. In einem üblichen Ba- 
chelorstudium gibt es üblicherweise nicht ausreichend Stundenvolumen, um einen 
Kurs vollständig dem Scheduling zu widmen (aber das kann für ein Masterstudi- 
um anders sein). Deshalb geben wir hier nur eine kurze Einführung in das Thema. 
Viele Scheduling-Algorithmen sind sehr komplex [38, 455] und häufig können nur 
annähernd optimale Ablaufpläne garantiert werden. Das wirft die Frage auf, welche 
Algorithmen hier präsentiert werden sollten. Wir werden in diesem Kapitel eine 


3 Pinedo bezeichnet den Makespan als Cmax. Mit der Bezeichnung M Smax möchten wir eine 
Verwechslung mit Ausführungszeiten vermeiden. 
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Auswahl an Algorithmen präsentieren, die in eingebetteten Systemen häufig benutzt 
werden. Eine Übersicht über die ausgewählten Algorithmen ist in Tabelle 6.1 zu 
sehen. Von links nach rechts betrachtet, beziehen sich die Spalten auf das Prozes- 


Tabelle 6.1 Scheduling-Algorithmen dieses Kapitels 


Qa B y Ab- |Algorithmus 
Proc. |r; \prmp|prec\periodic*| D; | prio |glob| Zielfkt. |schnitt 

1 |-| - - - Lmax 6.2.1 |Earliest Due Date 

1 |X} X - - Lmax 6.2.1 |Earliest Deadline First 

1 |X| X - - Lmax 6.2.1 |Least Laxity 

1 |X| - - - Lmax 6.2.1 |(Theorem 6.3) 

1 |X| X | X - Job Lmax 6.2.2 |Latest Deadline First 

1 |X| - X - Lmax 6.2.2 |Spring OS [508] 

1 |X} X - X = T; |Task < Di 6.2.3 |Rate Monotonic 

1 |X| X - X + T; |Task < Di 6.2.3 |Deadline Monotonic 
Pm|-| - - - X | m=|r| 16.3.1 |Bin Packing 
Pm|-| - - x È bi 6.3.1 |0/1 Multi-Knapsack 
Pm|X| X - X =T; < Di 6.3.1 |First Fit Decreasing 
Pm|X| X - X =T;\Job| X < Di 6.3.2 |Pfair 
Pm|X\ X - - Job | X < Di 6.3.3 |G-EDF, fpEDF, EDZL 
Pm|X| X x = T; |Task| X < Di 6.3.4 |G-RM, RM-US, RMZL 
Pm|X| X - X + T; |Task| X < Di 6.3.4 |Dichte-basiert 
Pm|-| - X - MSmax (6.4 |ASAP, ALAP 
Rm>|-| - | X - MSmax |6.43 [List Scheduling 
Pm|-| - X - MSmax |6.4.4 \Ganzz.Lin.Progr.(ILP) 
Rm X - MSmax |6.5.2 |HEFT, CPOP 
Rm|-| - X - MSmax |6.5.3 \ILP, z.B. [362] 
Rm |X| X | X - (X) |verschiedene|6.5.4 |DOL, HOPES, MAPS, 


a Algorithmen für aperiodische Task-Mengen können auch fiir periodische/sporadische Mengen 
benutzt werden. 
b List scheduling unterstützt heterogene Prozessoren nur eingeschränkt. 


sormodell, asynchrone Ankunftszeiten, Verdrängbarkeit, Reihenfolgebeschränkun- 
gen, periodische/sporadische vs. aperiodische Tasks bzw. Jobs, das Deadline-Modell 
(falls existent), Job- vs. Task-Prioritäten, globales vs. lokales Scheduling (für Mul- 
tiprozessoren), die Zielfunktion, den Unterabschnitt im Buch und den Namen des 
Algorithmus. Algorithmen wie Earliest Deadline First sind für nicht-periodische 
Systeme entwickelt, aber sie können auch auf periodische/sporadische angewandt 
werden. Aus der ersten Spalte geht hervor, dass heterogene Multiprozessoren nur 
durch die Algorithmen in den letzten drei Zeilen voll unterstützt werden. Uniforme 
Prozessoren werden nur als Anwendung des 0/1 Multi-Knapsack-Modells erwähnt. 
Verdrängungen sind nutzlos, wenn alle Jobs zu derselben Zeit ausführungsbereit 
werden (kenntlich gemacht durch ein ,,-” in der zweiten Spalte). Daher gibt es in 
diesem Fall in der dritten Spalte kein X. Einträge in der Spalte D; sind nur für 
periodische/sporadische Tasks relevant. Als Zielfunktion wird in vielen Fällen die 
maximale Verspätung benutzt. Für periodisches/sporadisches Scheduling ist die we- 
sentliche Frage aber: gibt es ein Schedule, welches die Deadline erfüllt? Bin packing 
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zielt vom Entwurf her auf die Minimierung der Anzahl der Prozessoren. Fiir HEFT 
und CPOP ist Makespan die relevante Zielfunktion. Nur die letzte Zeile entspricht 
der Minimierung mehrerer Kriterien, entweder in der Form eines einzelnen Krite- 
riums zur Zeit oder in Form einer multi-kriteriellen Optimierung auf der Basis der 
Pareto-Optimalitat. 

Ahnlich wie die Beurteilung der Rechenleistung ist auch das Scheduling ein 
Vorgang, der nicht nur ein einziges Mal während des Entwurfs durchgeführt wird. 
Vielmehr werden Scheduling-Algorithmen während des Entwurfs mehrfach benö- 
tigt. Grobe Abschätzungen können sogar erforderlich werden, wenn die Spezifikati- 
on verfasst wird. Später werden evtl. genauere Vorhersagen der Ausführungszeiten 
benötigt. Nach der Kompilierung gibt es noch genaueres Wissen über die Ausfüh- 
rungszeiten und dementsprechend können noch genauere Schedules erzeugt werden. 
Schließlich kann auch möglicherweise zur Laufzeit entschieden werden, welche 
Task/welcher Job als nächstes auszuführen ist. 

In der Praxis ist es sehr wichtig zu wissen, ob ein Schedule für eine gegebe- 
ne Menge an Tasks und Randbedingungen existiert. Eine Menge von Tasks heißt 
schedulable bei einer gegebenen Menge von Randbedingungen, wenn ein Schedule 
für diese Menge von Tasks und Randbedingungen existiert. Für viele Anwendun- 
gen sind Tests auf die Existenz eines Schedules (engl. schedulability tests) wichtig. 
Tests, die immer ein exaktes Ergebnis liefern, sind in vielen Fällen NP-hart [178]. 
Daher werden notwendige und hinreichende Tests benutzt. Für hinreichende Tests 
werden hinreichende Bedingungen für die Existenz eines Schedules geprüft. Es gibt 
eine (hoffentlich kleine) Wahrscheinlichkeit dafür, dass ein Schedule nicht garantiert 
werden kann, aber dennoch ein solches existiert. Notwendige Tests basieren auf not- 
wendigen Bedingungen. Mit ihnen kann gezeigt werden, dass kein Schedule existiert. 
Dennoch kann es Fälle geben, in denen die notwendigen Bedingungen erfüllt sind, 
aber trotzdem kein Schedule existiert. 


6.2 Scheduling für Einzelprozessoren 


Wir betrachten zunächst den Fall von Einzelprozessoren. In der Triplet-Notation 
entspricht dies dem Fall (1]..|..). Für diesen Abschnitt benutzen wir Material aus dem 
Buch von Buttazzo [81]. Für zusätzliche Referenzen sei auf dieses Buch verwiesen. 


6.2.1 Scheduling ohne Reihenfolgebeschränkungen 


Weiterhin betrachten wir zunächst Scheduling ohne Reihenfolgebeschränkungen, 
d.h. den Fall unabhängiger Jobs. 
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Earliest Due Date-Algorithmus 


Noch weiter einschränkend betrachten wir die Situation, in der alle Jobs gleichzeitig 
ausfiihrungsbereit werden und wir die maximale Verspätung minimieren wollen. 
Verdrängungen sind offenbar nutzlos, wenn alle Jobs zur selben Zeit ankommen. In 
der Triplet-Notation betrachten wir daher den Fall (1|..|Lmax). Für diesen Fall wurde 
von Jackson 1955 [264] eine sehr einfache Regel gefunden: 


Theorem 6.1 (Jacksons Regel): Wenn eine Menge von n unabhängigen Jobs gege- 
ben ist, so ist jeder Algorithmus, der die Jobs in der Reihenfolge nicht-abnehmender 
Deadlines ausführt, optimal in Bezug auf die Minimierung der maximalen Verspä- 
tung. 


Der Algorithmus, der dieser Regel folgt, heißt Earliest Due Date (EDD). Wenn 
die Deadlines vorab bekannt sind, kann EDD als ein statischer Algorithmus reali- 
siert werden. Für EDD müssen die Jobs nach ihren Deadlines sortiert sein. Seine 
Komplexität ist aufgrund des Sortierens O(n log(n)). 


Beweis (der Optimalität von EDD): Sei S ein Schedule, das durch irgendeinen 
Algorithmus A erzeugt wurde. Wenn A nicht die Wirkung von EDD hat, dann gibt 
es Jobs J, und Jp derart, dass die Ausführung von Jp derjenigen von J, vorangeht, 
obwohl die Deadline von J, kleiner ist als die von Jp (dg < dp). Wir betrachten nun 
ein Schedule S’ welches aus S durch Vertauschen der Ausführungsreihenfolge von 
Ja und Jp entsteht (siehe Abb. 6.4). 


S Jp| Ja 
S' Ja Jp 
fa =f'b 


Abb. 6.4 SchedulesS und S’ 


Für das Schedule S’ ist L,„„x(a,b) = max(LZ, L,,) die maximale Verspätung unter 
den Jobs Ja und Jp. L/, ist die maximale Verspätung von Job J, in Schedule S’. L; 
wird entsprechend definiert. Es gibt zwei mögliche Fälle: 


1. Lg > Lp: in diesem Fall haben wir 
De b) = = Ja -da 
Ja wird im neuen Schedule He beendet. Deswegen gilt 
Linax(a,b) = fa da < fa — da- 
Die rechte Seite dieser Ungleichung ist die maximale Verspätung in Schedule S. 
Pa gilt das folgende: 
(a,b) < Lmax(a, b) 


Lmax 
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2. L < Ly: 
In diesem Fall haben wir: 
Lmax(a,b) = fy, — db = fa — dp (siehe Abb. 6.4). 
Die Deadline von Ja liegt vor derjenigen von Jp. Dies führt auf 
Lmax(4, b) < Ja = da 
Wieder gilt: 
Lmax(a, b) < Lmax(a, b) 


Als Ergebnis kann jedes von einem EDD-Schedule verschiedene Schedule in endlich 
vielen Vertauschungen in ein EDD-Schedule transformiert werden, wobei die maxi- 
male Verspätung nur kleiner werden kann. Also ist EDD optimal für diese Klasse 
von Scheduling-Problemen. q.e.d. o 


Earliest Deadline First-Algorithmus 


Betrachten wir nun den Fall von unterschiedlichen Ankunftszeiten für ein Ein- 
zelprozessor-System. Bei diesem Szenario kann ein Verdrängen von Jobs (engl. 
preemption) potentiell die maximale Verspätung verbessern. In der Triplet-Notation 
entspricht dies dem Fall (1 | r;, prmp | Lmax). 

Der Earliest Deadline First (EDF)-Algorithmus ist optimal in Bezug auf die 
Minimierung der maximalen Verspätung. Er basiert auf folgendem Theorem [223]: 


Theorem 6.2: Wenn eine Menge von n unabhängigen Jobs mit beliebigen Ankunfts- 
zeiten gegeben ist, so ist ein Algorithmus, der zu jedem Zeitpunkt den ausfiihrungs- 
bereiten Job mit der frühesten absoluten Deadline ausführt, optimal in Bezug auf 
die Minimierung der maximalen Verspätung. 


Bei EDF muss jeder ankommende ausführungsbereite Job in eine Warteschlange 
von ausführbereiten Jobs eingefügt werden. Die Jobs in der Warteschlange sind nach 
ihrer Deadline sortiert. Wenn ein neu angekommener Job als erstes Element in die 
Warteschlange eingefügt wird, muss der gerade ausgeführte Job beendet werden. 


Beispiel 6.1: Abb. 6.5 zeigt ein EDF-Schedule. 


Ankunft | Dauer | Deadline 
i] 0 10 | 33 
Ankünfte Ja 4 3 28 
VEN „| 5 10 29 
Ji a ETT] | 
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Abb. 6.5 EDF-Schedule 
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Zum Zeitpunkt 4 hat Job Jz eine frühere Deadline. Daher wird J, verdrängt. Zur 
Zeit 5 wird J3 ausführungsbereit. Aufgrund der späteren Deadline wird Jz nicht 
verdrängt. J3 startet erst, wenn J2 beendet ist. Danach wird J3 bis zu seinem Ende 
ausgeführt. J; wird erst ausgeführt, wenn J3 beendet ist. Vv 


Wenn fiir die Warteschlange sortierte Listen verwendet werden, ist die Komplexitat 
von EDF O(n’). Sogenannte Bucket-Arrays können zur Reduktion der Laufzeit bei- 
tragen. Die Prioritäten sind offensichtlich dynamisch: sie hängen davon ab, welche 
Deadline die nächste ist. Da EDF dynamische Prioritäten benutzt, kann es es nicht 
mit einem Betriebssystem verwendet werden, welches nur statische Prioritäten un- 
terstützt. Allerdings wurde gezeigt, dass man Betriebssysteme so erweitern kann, 
dass EDF auf Anwendungsebene simuliert wird [132]. 


Beweis (des Theorems 6.2): Sei S ein Schedule, welches durch einen von EDF 
verschiedenen Algorithmus A erzeugt wird. Sei Sepr ein durch EDF erzeugtes 
Schedule. Wir zerlegen nunmehr die Zeitachse in diskrete Zeitabschnitte von jeweils 
einer Zeiteinheit*. Jeder Zeitabschnitt enthält die Zeiten im Intervall [t, +1). Sei 
S(t) der Job, der gemäß Schedule S im Zeitabschnitt [r, t+1) ausgeführt wird. Sei 
E(t) der Job, der zur Zeit t unter allen verfügbaren Jobs die früheste Deadline besitzt. 
Sei ferner tg(t) die Zeit (> t), zu welcher Job E(t) im Schedule S seine Ausführung 
beginnt. Schedule S ist kein EDF-Schedule. Daher gibt es eine Zeit t, zu der nicht 
der Job mit der frühesten Deadline ausgeführt wird. Für t gilt S(t) + E(t) (siehe 
Abb. 6.6). 


n Á —— 


Nn 
© 
o 
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= 
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0 1 2 3 4 5 6 


t=4 


Abb. 6.6 ScheduleS 


Mit denselben Argumenten wie bei Jacksons Regel können wir zeigen, dass die 
Vertauschung S(t) # E(t) wie in Abb. 6.7 nicht die maximale Verspätung erhöht. 

Daher kann jedes Schedule, das kein EDF-Schedule ist, durch eine begrenzte 
Anzahl von Vertauschungen in ein EDF-Schedule umgeformt werden, ohne die 
maximale Verspätung zu erhöhen. Also ist EDF unter den möglichen Algorithmen 
optimal. 

Wir können zeigen, dass das Vertauschen alle Deadlines einhält, sofern sie im 
Schedule S eingehalten wurden. Aufgrund der ursprünglichen Annahme ist die 


4 Dieser Beweis nimmt an, dass wir mit diskreten Zeiten arbeiten. Er kann auf reelle (kontinuierliche) 
Zeiten erweitert werden. 
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t=4 


Abb. 6.7 Schedule nach dem Vertauschen von Jobs S(t) und E(t) 


maximale Verspätung in Schedule S gleich 0. Deswegen und weil EDF ein Schedule 
mit minimaler Verspätung erzeugt, ist die maximale Verspätung des EDF-Schedules 
auch gleich Null. Daher ist das EDF-Schule für diese Problemklasse das optimale 
Schedule, das auch die Deadlines einhält. o 


Least Laxity-Algorithmus 


Wir wenden uns nunmehr der Betrachtung des Schlupfes (engl. laxity) zu und unter- 
suchen den Fall (1|r;, prmp, ..|..), wobei wir ein Schedule finden möchten, sofern es 
existiert. Least Laxity (LL), Least Slack Time First (LST) und Minimum Laxity First 
(MLF) sind drei Namen für eine Schlupf-basierte Scheduling-Strategie [349]. Beim 
LL-Scheduling sind die Prioritäten der Jobs eine monoton fallende Funktion ihres 
Schlupfs (siehe Gleichung (6.1); je weniger Spielraum ein Job also hat, desto höher 
seine Priorität). Der Schlupf verändert sich dynamisch. 


Beispiel 6.2: Abb. 6.8 zeigt ein Beispiel eines LL-Schedules mit den berechneten 
Laxity-Werten. 


Ankunft | Dauer Deadline 
J 0 10 
||| a | nen 
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Abb. 6.8 Least laxity-Schedule 
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Zum Zeitpunkt 4 wird Job J; wie oben verdrängt. Zum Zeitpunkt 5 wird Job J2 
nun auch verdrängt, weil er einen höheren Schlupf hat als Job J3. V 


LL ist auch ein verdrängendes (präemptives) Scheduling-Verfahren. Verdrängungen 
sind dabei nicht auf Zeitpunkte beschränkt, zu denen neue Jobs ausführungsbereit 
werden. Ein negativer Schlupf ist eine frühe Warnung für Deadlines, die verpasst 
werden. Man kann zeigen (in [349] ist dies als Übung dem Leser überlassen), dass 
LL auch ein optimales Scheduling-Verfahren für Einzelprozessor-Systeme in dem 
Sinne ist, dass es ein Schedule findet, wenn ein Schedule existiert. Wegen seiner 
dynamischen Prioritäten kann man es nicht in Standard-Betriebssystemen einsetzen, 
da diese üblicherweise nur statische Task-Prioritäten verwalten können. Im Gegen- 
satz zu EDF-Scheduling erfordert LL-Scheduling Wissen über die Ausführungszeit. 
Seine Anwendungsgebiete sind daher auf solche Situationen beschränkt, in denen 
seine Eigenschaften vorteilhaft sind. In den Unterabschnitten 6.3.3 und 6.3.4 wird 
gezeigt werden, dass der Schlupf im Multiprozessor-Scheduling eine Rolle spielen 
kann. 


Verfahren ohne Verdrängung 


Wir betrachten nunmehr den Fall, in dem Verdrängungen (engl. preemptions) nicht 
erlaubt sind, in unserer Klassifikation als (1|r;|Lmax) bezeichnet. 


Theorem 6.3: Wenn Verdrängungen nicht erlaubt sind, dann müssen optimale Sche- 
dules den Prozessor zu gewissen Zeiten unbeschäftigt lassen, damit spät eintreffende 
Jobs mit frühen Deadlines rechtzeitig beendet werden können. 


Beweis: Nehmen wir an, dass ein optimaler nicht verdrängender Scheduler (der 
kein Wissen über die Zukunft hat) den Prozessor immer auslastet. Dieser Scheduler 
muss das Schedule in Abb. 6.9 optimal erzeugen (d.h. er muss ein Schedule finden, 
wenn eines existiert). Für das Beispiel in Abb. 6.9 nehmen wir zwei Tasks an. Sei 


Abb. 6.9 Der Scheduler darf den Prozessor nicht vollständig auslasten 


Tı eine periodische Task mit C; = 2, Ti = 4, Dı = 4 und rı = O. Sei n eine 
sporadische Task mit Cp = 1, D2 = 1, Ph = 4 und m = 1, d.h. sporadisch zu 
Zeiten 4 x n + 1 ausführungsbereit werdend. Wir nehmen an, dass die gleichzeitige 
Ausführung beider Tasks aufgrund von Ressourcenkonflikten nicht möglich ist. 
Unter diesen Annahmen muss der Scheduler die Ausführung von Task rı zum 
Zeitpunkt O starten, da er ja den Prozessor voll auslasten soll. Da der Scheduler 
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nicht-verdrängend ist, kann er 72 nicht starten, wenn er zum Zeitpunkt 1 ausfüh- 
rungsbereit ist. Daher verpasst T2 die Deadline. Wenn der Scheduler den Prozessor 
nicht sofort belegt hätte (wie in Abb. 6.9 zum Zeitpunkt 4 gezeigt), hätte er ein 
zulässiges Schedule gefunden. Daher ist dieser Scheduler nicht optimal. Dies ist ein 
Widerspruch zur Annahme, dass optimale Scheduler existieren, die den Prozessor 
immer voll auslasten. o 


Abschließend stellen wir fest: um verpasste Deadlines zu vermeiden, muss der Sche- 
duler Wissen über die Zukunft haben. Solche Algorithmen heißen hellsehend (engl. 
clairvoyant). Ein Algorithmus, der Prozessoren trotz der Anwesenheit ausführungs- 
bereiter Tasks unbeschäftigt lässt, heißt nicht arbeitserhaltend. 


Definition 6.8: Ein Scheduling-Algorithmus heißt arbeitserhaltend (engl. work 
conserving), wenn es keine Zeiten gibt, zu denen der Prozessor unbeschäftigt ist, 
während es eine ausführungsbereite Task gibt [121]. 


Wenn es vorab keine Informationen über Ankunftszeiten gibt, dann kann kein on- 
line-Algorithmus entscheiden, ob er den Prozessor unbeschäftigt lassen soll. Wenn 
Ankunftszeiten a priori bekannt sind, wird das Scheduling-Problem im nicht ver- 
drängenden Fall im Allgemeinen NP-hart und Branch-and-Bound-Techniken werden 
typischerweise zur Erzeugung von Schedules verwendet. 


6.2.2 Scheduling mit Reihenfolgebeschränkungen 


Als nächstes betrachten wir die Ablaufplanung mit vorhandenen Reihenfolgebe- 
schränkungen, ausgedrückt durch eine Präzedenzrelation prec und in der Triplet- 
Notation als (1| r;, prmp, prec | Lmax) bezeichnet. 


Task-Graphen 


Reihenfolgebeschränkungen werden in gerichteten azyklischen Abhängigkeitsgra- 
phen (DAGs, siehe Definition 2.6) G = (t, E) ausgedrückt. Die Menge r stellt die 
Knoten (engl. vertices oder nodes) und E C T X T seine Kanten (engl. edges) des 
Graphen dar. 


Beispiel 6.3: In der Abb. 6.10 drücken die Kanten aus, dass die Quellknoten (die 
ersten Komponenten der Tupel, die eine Kante repräsentieren) vor den Zielknoten 
(die zweiten Komponenten der Tupel, die eine Kante repräsentieren) ausgeführt 
werden müssen. Die Knotenbeschriftungen bezeichnen Tasks. V 


Es gibt mehrere Gründe, Anwendungen in Form von DAGs zu beschreiben. 


1. Zum einen könnte jeder Knoten einer Task entsprechen und Kanten würden 
Abhängigkeiten zwischen Tasks repräsentieren. 
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Abb. 6.10 Reihenfolgebeschränkungen 


2. Zum anderen führt die Verfügbarkeit von Multiprozessoren zu der Idee der Auf- 
spaltung von Tasks in Subtasks und der Ausführung der Subtasks in überlappender 
Weise auf den verschiedenen Prozessoren. Das automatische Partitionieren von 
Tasks in Subtasks, sodass parallele Prozessoren effizient genutzt werden können, 
heißt automatische Parallelisierung. Automatische Parallelisierung ist sogar 
noch schwieriger als das automatische Scheduling für eine gegebene Menge von 
Subtasks (beispielsweise weil Datenabhängigkeiten analysiert werden müssen). 


Beide Fälle der Erzeugung von DAGs können auch in Kombination Anwendung 
finden: wir können Abhängigkeiten zwischen Tasks haben und Tasks können in 
Subtasks aufgespalten werden. Nachfolgend nehmen wir an, dass DAGs jede der 
eben beschriebenen Situationen repräsentieren können und wir sprechen in jedem 
Fall von Task-Graphen (siehe auch Seite 39). Für das Scheduling ist es unwichtig, 
wie der DAG erzeugt wurde. 


Beispiel 6.4: Abb. 6.11 zeigt ein gültiges Schedule für einen einfacheren Task- 
Graphen einschließlich Kommunikation. Task 73 kann nur ausgeführt werden, wenn 
Tı und n ausgeführt wurden und Nachrichten an 73 geschickt haben. 


Abb. 6.11 Reihenfolgebeschränkungen 
und Schedule 
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Latest Deadline First-Algorithmus 


Ein optimaler Algorithmus, der die maximale Verspätung im Falle gleichzeitig an- 
kommender Tasks oder Jobs minimiert, wurde von Lawler vorgestellt [327]. Dieser 
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Algorithmus heißt Latest Deadline First (LDF)-Algorithmus. LDF liest den Task- 
Graphen und speichert den Knoten, der die späteste Deadline und keine Nachfolger 
im Graphen hat, in einem Stapel. Dies wird für alle verbleibenden Knoten wiederholt, 
wobei immer der Knoten mit der spätesten Deadline unter allen Knoten mit bereits 
ausgewählten Nachfolgern gewählt wird. Dieser Knoten wird auf den Stapel gelegt. 
Zur Laufzeit werden die Tasks einer Reihenfolge ausgeführt, bei der wir die Einträge 
im Stapel von oben nach unten abarbeiten, d.h. in einer Reihenfolge, die gegenüber 
der Reihenfolge der Betrachtung der Knoten im Task-Graphen umgekehrt ist. LDF 
ist nicht verdrängend und optimal für Einzelprozessoren. 


Beispiel 6.5: Wir betrachten das Beispiel aus Abb. 6.11. LDF würde zuerst 73 auf 
dem Stapel ablegen, denn diese Task hat keinen Nachfolger. Danach sind alle Nach- 
folger von Tı und Tz bereits gewählt. Es hängt von der Deadline ab, welcher der 
Knoten als nächstes gewählt wird. Der Knoten mit der späteren Deadline wird als 
erstes auf den Stapel gelegt. Zur Laufzeit wird der Stapel in der umgekehrten Rei- 
henfolge abgearbeitet und beispielsweise mit der Bearbeitung von rı begonnen. V 


Im Falle von asynchronen Ankunftszeiten der Tasks kann man mit einem modifizier- 
ten EDF-Algorithmus ein gültiges Schedule bestimmen. Die Grundidee besteht darin, 
das Problem mit der gegebenen Menge abhängiger Tasks in eine äquivalente Men- 
ge unabhängiger Tasks mit unterschiedlichen Zeitparametern umzuwandeln [98]. 
Dieser Algorithmus ist wiederum optimal für Einzelprozessoren. 

Wenn Tasks nicht verdrängt werden dürfen, kann der heuristische Algorithmus 
aus [508] verwendet werden. 


6.2.3 Periodisches Scheduling ohne Reihenfolgebeschränkungen 


Jetzt betrachten wir periodische Abläufe. Wir werden anstelle von Jobs überwiegend 
Tasks betrachten, da sich im periodischen Fall die meisten Eigenschaften für Tasks 
zeigen lassen. Wir beschränken uns auf Tasks ohne Reihenfolgeabhängigkeiten, was 
in der Triplet-Notation durch das Triplet (1|r;,prmp, periodic] .. ) ausgedrückt werden 
kann. 


Notation 


Bei periodischem Scheduling sind die fiir aperiodisches Scheduling relevanten Ziele 
nicht sehr niitzlich. Beispielsweise spielt die Minimierung der totalen Dauer des 
Schedules keine Rolle, wenn wir eine unendliche Wiederholung von Jobs betrachten. 
Wir können bestenfalls einen Algorithmus entwerfen, der, falls ein Schedule existiert, 
dieses immer findet. Dies motiviert die Definition von Optimalität für periodische 
Schedules. 


Definition 6.9: Ein periodischer Scheduling-Algorithmus wird als optimal bezeich- 
net, wenn er immer ein Schedule findet, falls eines existiert. 
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Definition 6.10: Für periodische und sporadische Task-Systeme T = {T1,..,7„} de- 
finieren wir die Task-Auslastung (engl. task utilization) als 


uj = — (6.4) 


Damit benutzen wir für sporadische Systeme dieselbe Notation, obwohl 7; nur den 
minimalen Abstand zwischen zwei Jobs bedeutet. 


Definition 6.11: Für ein Task-System T = {Tj...T„} mit der Auslastung u; von Task 
Ti definieren wir das Maximum Umax und die Gesamtauslastung Usum durch: 


Umax = max (uj) (6.5) 


Usum = 3 ui (6.6) 


i 


Rate Monotonic Scheduling 


Rate Monotonic Scheduling (RMS) [348] ist wohl der bekannteste Scheduling- 
Algorithmus für unabhängige periodische Tasks. RMS basiert auf den folgenden 
Annahmen („RM-Annahmen‘“‘): 


. Alle Tasks mit harter Deadline sind periodisch. 

. Alle Tasks sind voneinander unabhängig. 

D; = T; für alle Tasks. 

. C; ist konstant und für alle Tasks bekannt. 

. Die Zeit für einen Kontextwechsel ist vernachlässigbar. 

. Für einen Prozessor und n Tasks wird die folgende Schranke bzgl. der Gesamt- 
auslastung Usum eingehalten: 


n 


Ci : 
Usum = 2,7, <n" -1) (6.7) 


i=l ' 


Abb. 6.12 zeigt Werte der Schranke in Ungleichung (6.7). 


Abb. 6.12 Werte der rechten 1 
Seite von Ungleichung (6.7) 


Ei 
w{ 7 0,828 
wo] 0,780 
At) 0,757 
a] 0,743 
oL nn] 0,734 
N] 0,728 
of] 0,724 
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Die Schranke fiir die Auslastung hat für große Werte von n einen Wert von ungefähr 
0,7: 


lim n » (2!/" — 1) = loge(2) = In(2) = 0,7 (6.8) 


Beim Rate Monotonic Scheduling ist die Priorität der Tasks eine monoton fallende 
Funktion ihrer Periode. Anders ausgedrückt, haben Tasks mit einer kurzen Periode 
eine höhere Priorität, wohingegen Tasks mit langer Periode eine geringere Priorität 
haben. RM-Scheduling ist verdrängend mit festen Prioritäten. 


Beispiel 6.6: Abb. 6.13 zeigt ein mit RMS erzeugtes Schedule. Pfeile mit zwei Spit- 
zen deuten die Ankunftszeiten einer Task und die Deadline der vorherigen Task an. 
Tasks T1, T2 und T3 haben jeweils eine Periode von 2, 6 und 6. Die Ausführungszeiten 
betragen 0,5, 2 und 1,75. Task qı hat die kürzeste Periode und daher die höchste 
Priorität. Die Task t2 wird mehrere Male verdrängt. Jedes Mal, wenn Task qı aus- 
führungsbereit ist, unterbricht ihr Job die gerade aktive Task. Task t2 hat die gleiche 
Periode wie Task t3, daher verdrängen sich diese beiden Tasks nicht. 


13 | m {m 
| | | | | | | | | z 
0 1 2 3 4 5 6 7 8 9 t 
Abb. 6.13 Beispiel eines RM-Schedules Vv 


Die Schranke in Ungleichung (6.7) erfordert, dass ein Teil der Rechenleistung des 
Prozessors unbenutzt bleibt, um sicherzustellen, dass alle Anforderungen rechtzeitig 
behandelt werden können. Warum gibt es diese Nutzungsschranke? Die Hauptursa- 
che dafür ist, dass die statischen Prioritäten des RMS bedingen, dass möglicherweise 
eine Task verdrängt wird, die nahe ihrer Deadline ist und dafür eine andere, höher 
priorisierte Task mit deutlich späterer Deadline zum Zuge kommt. Dadurch könnte 
die Task mit niedrigerer Priorität dann ihre Deadline verpassen. 


Lemma 6.1: Wenn die oben genannten sechs RM-Annahmen (siehe Seite 339) 
erfüllt sind, werden alle Deadlines garantiert eingehalten (siehe Buttazzo [&1]). 


Beispiel 6.7: Die Task-Parameter der Abb. 6.14 sind: 7; = 5,C1 = 3,7) = 8,05 = 3. 
Die Gesamtauslastung ist: Usum = 2 + Š = 2 = 0,975. Die Schranke der Unglei- 
chung (6.7) ist 2 * (23 -1) = 0,828. Die Schranke wird damit nicht eingehalten somit 
ist nicht garantiert, dass ein RM-Schedule existiert. Tatsächlich wird die Deadline 
zur Zeit 8 verpasst. Wir nehmen hier an, dass die Berechnungen, die ihre Deadline 


verpasst haben, nicht in der folgenden Periode nachgeholt werden. V 
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Abb. 6.14 RM-Schedule verpasst die Deadline zum Zeitpunkt 8 


Solche verpassten Deadlines können nicht auftreten, wenn die Prozessorlast sehr 
gering ist, sie treten dagegen möglicherweise bei hoher Prozessorlast auf, wie in 
Abb. 6.14 zu sehen. Wenn die Ungleichung (6.7) erfüllt ist, ist damit garantiert, 
dass die Prozessorauslastung gering genug ist, um Probleme wie in Abb. 6.14 zu 
vermeiden. Die Ungleichung (6.7) ist hinreichend, aber nicht notwendig. Es könnte 
damit ein RM-Schedule geben, obwohl die Ungleichung nicht erfüllt ist. Es gibt 
weitere hinreichende Schranken [54]. 

RMS hat die folgenden wichtigen Vorteile: 


e Unter den verdrängenden Scheduling-Algorithmen mit fester Priorität für Einzel- 
prozessoren ist RMS optimal [54]. 

e RMS basiert auf statischen Prioritäten. Das ermöglicht die Verwendung von 
RMS in Standard-Betriebssystemen, die feste Prioritäten unterstützen. 

e Wenn die sechs RM-Annahmen eingehalten werden, ist ein Schedule garantiert 
(siehe [81]). 


RMS ist die Basis vieler formaler Schedulability-Beweise. Bei der Konstruktion 
von Beispielen und beim Führen von Beweisen ist es hilfreich, zu wissen, welche 
Situationen hinsichtlich des Findens von Schedules mit RMS besonders kritisch sind. 
Wir setzen dazu zunächst folgende Eigenschaft voraus: 


Eigenschaft 6.1: Wir nehmen an, dass jeder Job beendet wird, bevor der nächste Job 
derselben Task ausführungsbereit wird. 


Definition 6.12: Ein kritischer Zeitpunkt (engl. critical time instant) für eine Task 
Ti ist der Zeitpunkt t, an dem ein Eintreffen der Task zur größten Antwortzeit führt. 


Theorem 6.4 (Critical instant theorem): Für ein Scheduling mit festen Prioritäten 
auf einem Einzelprozessor ist die Antwortzeit für jede Task t; maximiert, wenn T; 
gleichzeitig mit allen anderen Tasks einer höheren Priorität ausfiihrungsbereit wird. 


Beweis: Wir zeigen hier den originalen Beweis von Liu and Layland [348] in deut- 
scher Übersetzung und mit Anpassung an unsere Notation: „Sei T = {T1,...,7„} eine 
Menge von nach Prioritäten sortierten Tasks, wobei t,, die Task mit der niedrigsten 
Priorität ist. Wir betrachten ein Eintreffen von 7, zur Zeit tı. Wir nehmen an, dass 
zwischen der Zeit t; und der Zeit tı +T, (der Zeit, zu der die nächste Anforderung von 
Tn erfolgt) Task 7;, i < n, zu den Zeitpunkten fy, t2 +T;, t2 +2T;, ..., t2 + kT; ausfüh- 
rungsbereit wird, wie in Abb. 6.15 gezeigt. Offensichtlich wird die Verdrängung von 
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ty+(k+1) T; 
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Abb. 6.15 Verzögern von Task Tn durch höher priorisierte Task T; 


Tn durch q; eine gewisse Verzögerung bei der Ausführung der bei tı eintreffenden 
Instanz von T, bewirken, sofern nicht T, vor t fertig gestellt ist. Außerdem sehen 
wir aus Abb. 6.15, dass ein Vorziehen der Zeit t) die Fertigstellung von T, nicht be- 
schleunigen würde. Durch ein solches Vorziehen bleibt die Fertigstellung entweder 
unverändert oder sie wird verzögert. Also ist die Verzögerung in der Fertigstellung 
von Tn am größten, wenn fz und fı übereinstimmen. Wir beweisen das Theorem, 
indem wir das Argument für alle 7;,i = 2,...,m — 1, wiederholen.” oO 


Implizit haben wir die Eigenschaft 6.1 im Beweis benutzt. Wenn wir den allgemeinen 
Fall betrachten (d.h. den Fall, in dem die Eigenschaft 6.1 nicht gilt, siehe z.B. Baker 
[33]), dann bleibt Theorem 6.4 gültig, aber der Beweis wird komplexer, wie von 
Devillers et al. [129] und Bril [69] gezeigt°. 

Das Theorem von den kritischen Zeitpunkten hilft, Schedules für Einzelprozesso- 
ren zu finden. Leider gilt dieses Theorem nicht für Multiprozessor-Systeme, sodass 
Beweise wesentlich schwieriger werden. Man sollte sich also freuen, dass dieses 
Theorem für Einzelprozessoren gilt! 

Wir wollen uns nun andere Eigenschaften von RMS ansehen. Die freie Kapazität 
des Prozessors wird nicht immer benötigt. 


Theorem 6.5: Sei t ein System mit periodischen Tasks. Wenn die Periode aller Tasks 
ein Vielfaches der Periode der Task mit der höchsten Priorität ist, kann t mit RMS 
zeitlich eingeplant werden, wenn gilt: 


Usum < 1 (6.9) 


Beispiel 6.8: Diese Voraussetzung wird z.B. erfiillt, wenn Tasks eines Fernsehers 
mit den Raten von 25, 50 und 100 (oder 30, 60 und 120) Hertz ausgefiihrt werden 
müssen. V 


Beweis (von Theorem 6.5): Die Tasks seien nach Prioritäten sortiert, sodass gilt: 
Vi : T; < T;41. Wir betrachten eine Task t; und die Task mit der nächstniedrigeren 
Priorität, Task T;+1 (siehe Abb. 6.16). Die zweite Deadline von T;+ passt sehr schön 


5 Ich verdanke diesen Hinweis J.J. Chen von der TU Dortmund. 
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Abb. 6.16 Falten von Tasks benachbarter Prioritäten 


zur vierten Deadline von t;. Deshalb können wir die Ausführungszeiten von Task 
Ti+1 in die Ausführungszeiten von Task 7; hinein falten und eine neue Task TA 
erzeugen, welche die Ausführungszeiten der beiden ursprünglichen Tasks enthält. 
Dieses Falten ist möglich, wenn die gesamte Ausführungszeit der beiden Tasks nicht 
die Periode von T;+ı übersteigt. Dieses Verfahren kann in derselben Weise mit der 
Task der nächstniedrigeren Priorität wiederholt werden. Dieses Falten ist möglich, 


solange die Gesamtauslastung nicht größer ist als 1. o 


Die Schranken in den Ungleichungen (6.7) oder (6.9) erlauben einen einfachen Test 
für die Existenz eines Schedules. 

Aufgrund des Theorems der kritischen Zeitpunkte muss man beim Beweis der 
Optimalität von RMS nur den Fall betrachten, in dem alle Tasks gleichzeitig mit 
allen anderen einer höheren Priorität ausführungsbereit werden. 


Earliest Deadline First Scheduling 


EDF kann auch auf Mengen periodischer Tasks angewendet werden. Es reicht of- 
fensichtlich aus, das Scheduling-Problem für eine einzelne Hyperperiode wie ein 
aperiodisches Scheduling-Problem zu lösen. Die Lösung kann dann für alle weiteren 
Hyperperioden angewandt werden. So beträgt beispielsweise die Dauer der Hyper- 
periode für das Beispiel von Abb. 6.14 40 Zeiteinheiten. Aus der Optimalität von 
EDF für nicht-periodische Schedules ergibt sich, dass EDF auch für eine einzelne 
Hyperperiode optimal ist, damit also auch für das gesamte Scheduling-Problem. Es 
müssen also keine weiteren Bedingungen eingehalten werden, um die Optimalität 
des Verfahrens zu garantieren. Daraus folgt, dass EDF auch für den Fall Uşum = 1 
optimal ist. 


Beispiel 6.9: Dementsprechend wird keine Deadline verpasst, wenn für das Beispiel 
aus Abb. 6.14 EDF-Scheduling verwendet wird (siehe Abb. 6.17). Zum Zeitpunkt 5 
unterscheidet sich das Verhalten von dem Verhalten bei RM-Scheduling: durch die 
frühere Deadline von Tz wird diese Task nicht verdrängt. 


344 6 Abbildung von Anwendungen 


a E E BE BES E 


7 DEN mu mm 


DT mg 
0 2 4 6 8 10 12 14 16 18 20 22 24 t 


Abb. 6.17 Mit EDF erzeugtes Schedule fiir das Beispiel aus Abb. 6.14 Vv 


Tasks mit expliziter Deadline 


Nunmehr gehen wir über zur Betrachtung von Tasks, deren Deadline von der Periode 
verschieden ist. Solche Tasks heißen Tasks mit expliziter Deadline. In einem solchen 
System ist jede Task durch ein Tripel (C;, Di, T;) charakterisiert, wobei D; die relative 
Deadline ist. Der Fall D; < T; heißt constrained deadline-Fall. Wenn eine solche 
Einschränkung nicht existiert, sprechen wir von einer beliebigen Deadline (engl. 
arbitrary deadline). Offensichtlich ist der Fall einer expliziten Deadline allgemeiner 
als der Fall einer impliziten Deadline und jede Task mit impliziter Deadline ist auch 
eine Task mit expliziter Deadline. 

Bei Tasks mit expliziter Deadline ist die Auslastung nur sehr begrenzt zur Charak- 
terisierung der Rechenanforderungen geeignet. In gewissem Umfang spielt nunmehr 
die Dichte (engl. density) die Rolle, welche bislang die Auslastung spielte. Die 
Dichte ist wie folgt definiert: 


Ci 


i = — 1 

dens minI) (6.10) 

denssum(T) = > dens; (6.11) 
Tet 

densmax(T) = max(dens;) (6.12) 
Ti ET 


Werte der Dichte charakterisieren Rechenzeitanforderungen. Die Demand-Bound- 
Function (DBF) liefert allerdings bessere Schranken: 


Definition 6.13: Die Demand-Bound-Function DB F(z;, t) ist, für jede sporadische 
Task t; und jede reelle Zahl t > 0, die größte aufsummierte Rechenanforderung 
aller Jobs, die von T; erzeugt werden können und die sowohl den Zeitpukt der 
Ausführbarkeit wie auch die Deadline in einem zusammenhängenden Intervall der 
Länge t haben. 


Die aufsummierten Rechenanforderungen von Task 7; in einem Intervall [fo, to + £) 
sind maximiert, wenn einer ihrer Jobs zu Beginn des Intervalls eintrifft (d.h. zur Zeit 
to) und die nachfolgenden Jobs treffen so schnell wie erlaubt ein, d.h. an Zeitpunkten 
to+T;, to +2T;, to+3T;, .... Diese Beobachtung führt uns zur Gleichung (6.13) [40, 38]: 
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DBF(z;,t) = max Gk au + 1) * c (6.13) 


L 


Die Dichte und die DBF hängen miteinander zusammen: 
Lemma 6.2: Für alle Tasks t; und fiir alle t > 0: 
t x dens; => DBF(z;,t) (6.14) 


Beweis: Wir vergleichen die graphischen Darstellungen der Dichte und der DBF 
als eine Funktion der Zeit. Abb. 6.18 zeigt die beiden Funktionen. Die linke Seite 


DBF, dens dais 
Pr a DBF 
Z > 
D; D+T. D+2T D+ST. t 
l l i i i 1 


Abb. 6.18 Vergleich von Dichte und DBF 


der Gleichung (6.14) ist als gerade Linie mit Steigung dens; dargestellt. Die DBF 
ist eine Stufenfunktion mit Stufen der Höhe C;. Die Stufenfunktion steigt um C; 
jedes Mal, wenn eine Task ausgeführt werden muss. Die erste Stufe ist bei t = Dj. 
Aufgrund der Definition der Dichte übersteigt diese Stufe nie die gerade Linie. Die 
nächsten Stufen gibt es bei t = D; + 7;, t = Di + 2T;, t = Di + 3T; usw. Auch diese 
Stufen werden die Gerade nicht überschreiten. o 


EDF kann leicht auf den Fall der von den Perioden verschiedenen Deadlines 
erweitert werden. Für RMS heißt die Erweiterung Deadline Monotonic Scheduling 
(DMS). 


Deadline Monotonic Scheduling 


Tasks mit expliziten Deadlines können mit Deadline Monotonic Scheduling (DMS) 
zeitlich eingeplant werden. Statische Task-Prioritäten basieren bei DMS auf nicht- 
aufsteigenden Deadlines: für zwei Tasks 7; und t; ist die Priorität von 7; größer als 
die von Tt; wenn D; < Dy ist. 

Für constrained deadline-Tasks kann die Schranke in Ungleichung (6.7) zur 
Schranke in Ungleichung (6.15) verallgemeinert werden. Diese ist hinreichend, aber 
nicht notwendig [81]. 
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> Gee nam — 1) (6.15) 
i=l Di 


6.2.4 Periodisches Scheduling mit Reihenfolgebeschrankungen 


Scheduling für abhängige Tasks ist schwerer als das Scheduling für unabhängige 
Tasks, v.a. falls keine Verdrängungen erlaubt sind (in der Triplet-Notation im Fall 
(1|r;,prec, periodic|Lmax)). Das Entscheidungsproblem hinsichtlich der Existenz ei- 
nes Schedules für eine Menge abhängiger Tasks und einer gegebenen Deadline ist 
NP-hart [178]. Es gibt verschiedene Strategien, um die Komplexität zu senken: 


e Es werden zusätzliche Ressourcen bereit gestellt, sodass das Scheduling einfacher 
wird. 

e Das Scheduling wird in statische und dynamische Anteile zerlegt. Bei diesem 
Ansatz werden so viele Entscheidungen wie möglich zur Entwurfszeit getroffen 
und der verbleibende Rest wird zur Laufzeit vorgenommen. 


6.2.5 Sporadische Ereignisse 


Prinzipiell könnte man sporadische Ereignisse mit Interrupts verbinden und sie jedes 
Mal sofort ausführen, wenn die Interrupt-Priorität die höchste im gesamten System 
ist. Das hätte allerdings ein unvorhersagbares Verhalten für alle anderen Tasks zur 
Folge. Daher werden besondere sporadic task server verwendet, die regelmäßig 
ausgeführt werden und dabei prüfen, ob ausführungsbereite sporadische Ereignisse 
existieren. So können sporadische Ereignisse praktisch in periodische Tasks umge- 
wandelt werden, wodurch die Vorhersagbarkeit des Gesamtsystems deutlich verbes- 
sert wird. 


6.3 Scheduling für unabhängige Jobs auf identischen 
Multiprozessoren 


Aufgrund der großen Verbreitung von Mehrkern-Systemen in aktuellen eingebette- 
ten Systemen betrachten wir als nächstes Multiprozessor-Systeme. Beim Übergang 
von Einzelprozessoren zu Multiprozessor-Systemen muss eine Vielzahl von Heraus- 
forderungen bewältigt werden. Zunächst betrachten wir den Fall von m identischen 
Prozessoren. Weiterhin gehen wir von einem Task-System T = {T1,...,7n} aus, bei 
dem jede Task i durch ihre größtmögliche Ausführungszeit C; und — bei periodischen 
und sporadischen Tasks - ihre Periode charakterisiert ist. Sofern nichts anderes ge- 
sagt ist, nehmen wir an, dass die Periode auch die Deadline ist. Wenn die periodische 
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oder sporadische Natur der Tasks nicht relevant ist, können wir auch eine Menge von 
Jobs mit expliziten Deadlines d; betrachten. 

Fiir Multiprozessoren ist es nicht ausreichend, zu entscheiden, wann Tasks oder 
Jobs ausgefiihrt werden. Vielmehr miissen wir entscheiden, wann und wo wir diese 
ausfiihren wollen. 

Fiir m identische Prozessoren gibt es die folgenden notwendigen Schranken fiir 
die Existenz eines Schedules: 


Vis uj <1 (6.16) 
Usum < m (6.17) 


6.3.1 Partitioniertes Scheduling 


Unsere Darstellung in den nächsten Abschnitten basiert v.a. auf einem Buch von 
Baruah et al. [38] sowie auf einem Übersichtspapier von Davis et al. [121] und 
Folien von I. Puaut [461, 462]. Baruah et al. konzentrieren sich dabei auf sporadische 
Task-Systeme. Dies wird zum Teil dadurch motiviert, dass sporadische Systeme — im 
Gegensatz zu periodischen Task-Systemen — keine globale Zeitsynchronisation für 
das Bereitstellen von Jobs benötigen. Es reicht aus, wenn wir mit einem Zeitgeber 
sicherstellen, dass die minimalen Zeitabstände eingehalten werden. 

Weiterhin beschränken wir uns zunächst auf partitioniertes Scheduling. Dies 
bedeutet, dass jede Task einem bestimmten Prozessor zugeordnet ist. Die Verlage- 
rung von Tasks (auf andere Prozessoren) ist nicht erlaubt. Partitioniertes Scheduling 
bei synchronen Ankunftszeiten kann mit bin-packing realisiert werden. Bin-packing 
[307] kann in einer auf das Scheduling angepassten Notation wie folgt beschrieben 
werden: 


Definition 6.14: Sei t = {1,...,n} eine Menge von Objekten, wobei jedes Objekt 
i € reine Größe c; € (0, 1] besitzt. Sei z = {1,...m} eine Menge von Behältern mit 
der Kapazität 1. Das Problem, eine Zuordnung a : T — ~ so zu finden, dass die 
Anzahl nicht-leerer Behälter m < n minimal ist und dass die Kapazität der Behälter 
nicht überschritten wird, heißt bin packing-Problem. 


Bin packing ist NP-hart [178]. Daher benötigen optimale Algorithmen wie der 
von Korf [306] große Laufzeiten. Die Formalisierung des Scheduling-Problems als 
bin packing-Problem zielt auf die Minimierung der Anzahl der Prozessoren m. 

Für eine gegebene Anzahl m von Prozessoren ist es angemessener, Scheduling 
für synchrone Ankunftszeiten als ein Rucksack-Problem (engl. knapsack problem) 
zu modellieren, genauer gesagt, als ein 0/1-Multiples Knapsack-Problem (MKP). 


Definition 6.15 (Martello [368]): Sei t = {1,...,n} eine Menge von n Objekten, 
jedes mit einer Größe c; und einem Nutzen b;. Sei z eine Menge von m Rucksäcken, 
jeder mit einer Kapazität xx, mit (m < n). Wir gehen davon aus, dass wir einen 
Teil der Objekte den Rucksäcken so zuordnen können (a : T — x7), sodass die 
Größenbeschränkungen eingehalten werden: 
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Vk: > Ci < Kg. (6.18) 


i,a:i—>k 


Das Problem der Auswahl einer Teilmenge von Objekten derart, dass der Gesamt- 
profit >); b; für die Objekte in den Rucksäcken maximiert wird, heißt 0-1-Multiple- 
Knapsack-Problem (MKP). 


Unter Ausnutzung eines Algorithmus für das MKP können wir Jobs m Prozes- 
soren zuordnen. Dabei würden wir evtl. nicht alle Jobs wirklich einem Prozessor 
zuordnen können. Bei identischen Prozessoren wären alle Kapazitäten gleich. Für 
uniforme Prozessoren können wir die Kapazität benutzen, um die Geschwindigkei- 
ten bzw. die Performanz der Prozessoren zu modellieren. Das MKP ist ebenfalls 
NP-hart. 

Aufgrund der Komplexität des Schedulings für synchrone Ankunftszeiten gibt es 
keine Hoffnung auf effiziente optimale Algorithmen für das allgemeine Problem. In 
der Praxis werden daher Heuristiken benutzt. Diese betrachten Tasks und Prozessoren 
in einer bestimmten Reihenfolge und sie unterscheiden sich in der Reihenfolge, 
die sie nutzen. Lopez et al. [356] haben verschiedene Heuristiken verglichen. Sie 
beschränken sich auf sogenannte vernünftige Zuordnungsalgorithmen. 


Definition 6.16: Ein vernünftiger Zuordnungsalgorithmus (engl. reasonable alloca- 
tion (RA) algorithm) ist ein Algorithmus, der nur dann einer Task keinen Prozessor 
zuordnet, wenn die Task auf keinen der Prozessoren der Plattform passt. 


Definition 6.17: Ein vernünftiger abnehmender Zuordnungsalgorithmus (engl. rea- 
sonable allocation decreasing (RAD) algorithm) ist ein RA-Algorithmus, der Tasks 
in nicht-aufsteigender Reihenfolge der Auslastung betrachtet. 


Die von Lopez et al. untersuchten Algorithmen kombinieren alle möglichen Kom- 
binationen von zwei Eigenschaften: 


1. Die Reihenfolge, in der Tasks betrachtet werden: Tasks können in absteigender 
Reihenfolge der Auslastung (bezeichnet als D), aufsteigender Reihenfolge der 
Auslastung (bezeichnet als I) und in beliebiger Reihenfolge (bezeichnet durch 
keinen Buchstaben) betrachtet werden. 

2. Die Suchstrategie der Prozessorzuordnung. Wir nehmen an, dass die Prozessoren 
in einer bestimmten Weise geordnet sind. Die first fit-Strategie (bezeichnet als 
FF) wird dann eine Task dem ersten Prozessor zuordnen, auf den sie passt. Die 
worst fit-Strategie (bezeichnet als WF) wird dann eine Task dem Prozessor mit 
der größten verbleibenden Kapazität zuordnen. Die best fit-Strategie (bezeichnet 
als BF) wird dann eine Task dem Prozessor mit der kleinsten noch ausreichenden 
verbleibenden Kapazität zuordnen. 


Es gibt insgesamt neun Kombinationen. Alle können effizient realisiert werden. 
Beispielsweise sieht der Algorithmus FFD wie folgt aus: 
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Sortiere die Task-Menge nach nicht-aufsteigenden Auslastungen u; = Ci / Ti; 
/* Annahme: Task-Menge wird entsprechend der Sortierung neu nummeriert; */ 


for (mt=0; mt < m; mt++) K[mt] =1; /* initialisiere die Kapazität */ 
for (i=1; isn; i++) { /x für jede Task */ 
for (mt=1; (u; >K[mt]) and (mt<m); mt++); /* ausreichend Kapazität? */ 
if (mt > m) mt=0; /* keine Lösung, wähle Index @ */ 
ali]=mt; /* Gib Prozessorzuordnung im Array zurück */ 
K[mt]=K[mt]-u; ; /* Aktualisiere verbleibende Kapazität */ 
} 


Der heuristische Algorithmus ist sicherlich nicht optimal. Wir können uns fragen: 
wie weit sind wir vom Optimum entfernt? Viele Publikationen diskutieren obere 
Schranken für die Anzahl von zusätzlichen Prozessoren, die im Vergleich mit der 
minimalen Anzahl von Prozessoren beim optimalen bin packing benötigt werden. 
Die Publikation von Dosa [136] ist ein Beispiel dafür. Für Echtzeitsysteme ist eine 
andere Frage relevant: Gibt für eine gegebene Anzahl von Prozessoren eine obere 
Schranke für die Auslastung, bis zu der ein Schedule garantiert ist? Eine solche 
Schranke wurde von Lopez et al. [356] bewiesen: 


Theorem 6.6: Jeder RA-Algorithmus hat eine Auslastungsschranke nicht kleiner als 


Up Umax) =m- (m - 1)Umax (6.19) 


Beweis: Wenn eine Task mit einer Auslastung u; nicht zugeordnet werden kann, 
dann muss jeder Prozessor bereits Tasks so zugeordnet bekommen haben, dass seine 
Auslastung (1 — u;) übersteigt. Die Gesamtauslastung über alle zugeordneten Tasks 
und 7; einschließend muss dann größer sein als 


m(l-uw)+u =m-(m-1])u; (6.20) 
> m-(m- 1)Umax (6.21) 
Diese Bedingung muss erfüllt sein, damit kein Schedule möglich ist. Oo 


Weiterhin definieren wir £ als 


1 
= 6.22 
B | U | (6.22) 
ß ist eine untere Schranke für die Anzahl von Tasks, die wir auf einem einzelnen Pro- 
zessor ausführen können. Wir nehmen an, dass auf jedem Prozessor EDF als lokales 
Scheduling-Verfahren genutzt wird. Lopez et al. zeigten das folgende Theorem: 


Theorem 6.7: Kein Zuordnungsalgorithmus kann eine Auslastungsschranke haben, 


die größer ist als 


Bm+1 


Up2(B) = B+1 


(6.23) 
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Beweis: Siehe Lopez et al. [356]. 


Lopez et al. haben auch gezeigt, dass WF und WFI Gleichung (6.19) als ihre 
untere Schranke haben, die anderen Algorithmen haben Gleichung (6.23) als ihre 
untere Schranke. Die Schranke in Gleichung (6.19) nähert sich 1, wenn Umax sich 
der 1 nähert: 


Uzı(l)=1 (6.24) 
Wenn Umax Sich der 1 nähert, so nähert sich 6 ebenfalls der 1 und für Ua gilt: 


m+1 
2 


Up(l) = (6.25) 

Verglichen mit der Schranke in Gleichung (6.24) erlaubt uns die Schranke in 
Gleichung (6.25) mehrere Prozessoren effizienter nutzen. Aufgrund dieser Schranken 
sind daher WF und WFI schlechter als die anderen sieben Algorithmen. Empirisch 
wurde gezeigt, dass FFD besser zu sein scheint als FF oder FFI und BFD scheint 
besser zu sein als BF und BFI [33]. Es gibt auch theoretische Anhaltspunkte, welche 
diese Beobachtung unterstützen [38]. 

Die skizzierten neun Algorithmen sind relativ einfache Algorithmen. Wir neh- 
men davon Abstand, ausgefeiltere Algorithmen für dasselbe Problem zu präsentieren, 
denn das Problem ist zu stark vereinfacht, um realistische Anwendungen widerzu- 
spiegeln. 


e Das Scheduling-Problem, wie es in diesem Abschnitt behandelt wurde, ist ein sehr 
eingeschränktes. Es gibt keine Reihenfolgebeschränkungen, keine Verdrängungen 
und nur identische Prozessoren. 

e Partitioniertes Scheduling kann selbst dann, wenn Jobs ausführungsbereit sind, 
zu unbenutzten Prozessoren führen. Daher ist partitioniertes Scheduling nicht 
arbeitserhaltend (engl. work conserving). Folglich ist Optimalität nicht garantiert. 


Mithin enthält dieser Abschnitt Basiswissen, aber praktische Probleme benötigen 
ausgefeiltere Ansätze, wie die in den nachfolgenden Abschnitten präsentierten. 


6.3.2 Globales Scheduling mit dynamischen Prioritäten 


Globales Scheduling kann verhindern, dass trotz vorhandener ausführbarer Jobs ei- 
nige Prozessoren unbenutzt sind. Beim globalen Scheduling ist die Zuordnung von 
Prozessoren zu Tasks oder Jobs dynamisch. Dies gibt uns mehr Flexibilität, v.a. 
in Gegenwart von sich verändernden Arbeitslasten oder sich ändernden Verfügbar- 
keiten von Prozessoren. Aufgrund des Fortfalls von Ausführungsbeschränkungen 
werden die oberen Schranken der Auslastungen wie in den Gleichungen (6.19) und 
(6.23) ersetzt durch: 


Usum < m (6.26) 
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Allerdings bringt es diese bessere Auslastung mit sich, dass zusätzlicher Over- 
head für Scheduling-Entscheidungen, Verdrängungen und Verlagerungen von Jobs 
entsteht. 


Proportional fair (Pfair) scheduling 


Die Grundidee von proportional fair (pfair)-Scheduling [39] ist es, jede Task mit 
einer Rate auszuführen, die proportional zu ihrer Auslastung ist. Wenn wir bei- 
spielsweise eine 50-prozentige Auslastung (d.h. u; = 0,5) für eine Menge von Tasks 
haben, dann sollte jede Task etwa zur Hälfte der Zeit ausgeführt werden, unabhängig 
von der Anzahl der Prozessoren. Für pfair-Scheduling setzen wir voraus, dass die 
Zeit quantisiert ist und mit ganzen Zahlen abgezählt ist. Jedes derart abgezählte 
Zeitintervall nennen wir einen Zeitschlitz (engl. time slot). Ebenso nehmen wir an, 
dass die C; und T;-Parameter von ganzen Zahlen repräsentiert werden. 


Definition 6.18: Der Verzug (engl. lag) einer Task 7; zur Zeit t in Bezug auf ein 
Schedule S, bezeichnet als lag(S,7;,t), ist die Differenz zwischen der Anzahl von 
Prozessorzeitschlitzen, die der Task schon zugewiesen wurden, und der Anzahl, 
welche die Task schon bekommen sollte: 


1-1 
lag(S,7;,t) = uj * t — > alloc(S,7;,u) (6.27) 
u=0 


Der erste Term ist die gewünschte Ausführungszeit der Task t;, der zweite Term 
ist die realisierte Ausführungszeit im Schedule S. Ein Schedule heißt pfair-Schedule, 
wenn der Verzug im Intervall (—1, +1) bleibt. 


Beispiel 6.10: Abb. 6.19 zeigt die realisierte Ausführungszeit als Funktion der realen 
Zeit. Die tatsächliche Ausführungszeit sollte die beiden gestrichelten Linien nicht 
erreichen. 


N Ausführungszeit = j -7 


Abb. 6.19 Ausführungszeit als Funktion der Zeit Vv 


6 Die Darstellung von pfair-Scheduling basiert auf Folien von I. Puaut [462]. 
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Für das pfair-Scheduling teilen wir jede Task t; in Subtasks rj auf, wobei j 
die Ausführungsintervalle aufzählt. Für jede Subtask definieren wir eine Pseudo- 
Bereitstellungszeit r(t; ) und eine Pseudo-Deadline d(T? ): 


ie ys | (6.28) 
dG? y= [2 (6.29) 


Beispiel 6.11: Betrachte eine Task 7; mit C; = 8,7; = 11. Mögliche Intervalle für 
die Anzahl der realisierten Ausführungszeitschlitze sind für jedes j in Abb. 6.20 
gezeigt. 


Abb. 6.20 Mögliche Intervalle realisierter Ausführungszeit 


Beispielsweise gilt: 


s_|6-1| |55| _ 
re) =| |-[ E 


no-i 


Daher muss die sechste Subtask von 7; im Intervall (6:9) ausgeführt werden. V 


Ein spezieller Ansatz für die Zuordnung von einer korrekten Anzahl von Zeit- 
schlitzen wird in dem Buch von Baruah et al. [38] vorgestellt. Im Allgemeinen gibt 
es Variationen dieses Schemas: wir können EDF auf Pseudo-Deadlines anwenden 
oder wir können EDF modifizieren, indem wir Regeln definieren, die im Fall eines 
Gleichstands der Scheduling-Kriterien gelten. Es ist möglich, bis zu einer vollen 
Prozessor-Auslastung, d.h. Usum < m, Schedules zu garantieren. 

Potentiell leidet pfair-Scheduling unter einer großen Zahl von Verlagerungen hin 
zu anderen Prozessoren. Aufgrund der Überapproximation der Ausführungszeiten 
durch ganze Zahlen ist es nicht arbeitserhaltend. Es wurden Varianten vorgeschlagen, 
welche die Anzahl von Job-Verlagerungen reduzieren. Auch kann die Komplexität bei 
manchen Varianten reduziert werden. Pfair-Scheduling findet viele Anwendungen 
in Betriebssystemen, beispielsweise beim Scheduling in virtuellen Maschinen. 
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6.3.3 Globales Scheduling für feste Job-Prioritäten 


G-EDF-Scheduling 


Wir können versuchen, das zweidimensionale Problem mit Erweiterungen von Sche- 
duling-Algorithmen für Einzelprozessoren zu lösen. Beispielsweise können wir Glo- 
bal EDF (G-EDF) benutzen. G-EDF definiert — wie EDF — Job-Prioritäten anhand 
der Nähe der nächsten Deadlines. Wenn m Prozessoren verfügbar sind, werden jene 
m Jobs ausgeführt, welche die höchsten Prioritäten unter allen verfügbaren Jobs ha- 
ben. Offensichtlich sind solche Prioritäten abhängig vom Job und nicht nur von der 
Task. In einer globalen Scheduling-Strategie möchten wir preemptions von Jobs und 
Verlagerungen von Jobs zu anderen Prozessoren möglichst selten haben. Für G-EDF 
hängt die Häufigkeit davon ab, wie wir Tasks oder Jobs den Prozessoren zuordnen 
[189]. 


Lemma 6.3: G-EDF ist nicht optimal. 


Beweis: Der Beweis erfolgt durch Gegenbeispiel, übernommen von Cho et al. [101]. 
Wir betrachten ein Task-System mitm = 2 und C; = 3, Dj = 4, Cp = 2, D2 = 3, 
C3 = 2 und D3 = 3. In Abb. 6.21 (links) ist zu sehen, dass G-EDF aufgrund der 
früheren Deadline Jı und Jz zuerst einplant. J; verpasst die Deadline, obwohl ein 
Schedule möglich ist, wie in Abb. 6.21 (rechts) gezeigt. 


Abb. 6.21 Links: G-EDF verpasst Deadline bei t = 4; rechts: mögliches Schedule 


oO 


Das Problem rührt offenbar von der Unfähigkeit her, den zweiten Prozessor fiir 
t > 2 zu nutzen. 

Allgemein leidet G-EDF unter Anomalien wie dem sogenannten Dhall-Effekt 
[130]: periodische Task-Mengen, in denen eine Task eine Auslastung nahe Eins hat, 
können nicht mit G-EDF eingeplant werden. 


Beispiel 6.12: Wir betrachten den Fall n = m + 1, um den Effekt zu demonstrieren. 
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Vi € [l..m] : T; = 1,C; = 2e,u; = 2& (6.30) 
Tm+1 = l + £, Cm+1 = l, Um+1 = En (6.31) 
Abb. 6.12 zeigt ein entsprechendes 

Schedule. Anfangs werden nur Tasks fi = | 

T1,..Tm ausgeführt. Die Ausführung von .. nun | 

Task Tm+1 startet erst, nachdem die ers- | 

ten m Tasks ihre Ausführung beendet tm = | 

haben. Task Tm+1ı verpasst ihre Deadli- + mai t | 

ne. Die Anwesenheit einer einzigen Task 

Tm+1 mit hoher Auslastung ist ausrei- ~ TT F 

chend, um eine Deadline bei t = 1 +€ 0 2e 1 ~dte 


zu verpassen. Dies passiert, obwohl die 
Auslastung der anderen Tasks sehr klein 
ist. Tatsächlich kann die Auslastung für die Tasks 11, ..Tm beliebig klein sein und wir 
verpassen immer noch die Deadline. V 


Abb. 6.22 Dhall-Effekt 


Dies motiviert uns, Varianten von Algorithmen zu nutzen, die Tasks mit einer 
hohen Auslastung eine hohe Priorität zuweisen, unabhängig von der Deadline oder 
der Periode. 

Algorithmus fpEDF ist ein solcher Algorithmus. Wir nehmen an, dass ein spo- 
radisches Task-System T = {Tı,...7„} mit impliziten Deadlines gegeben ist und 
dass Tasks nach nicht-aufsteigenden Task-Auslastungen u; sortiert sind. Unser Ziel 
ist es, einen Ablaufplan (Schedule) für die Ausführung dieser Tasks auf m identi- 
schen Prozessoren zu entwickeln, wobei der Dhall-Effekt vermieden werden soll. 
Der fpEDF-Algorithmus arbeitet wie folgt [38]: 


for (i=1; i < m-1; i++){ 
if (u; >0.5) die Jobs von T; erhalten die höchste Priorität 
/* Bei Gleichstand erfolgt eine beliebige Auswahl */ 
else break; 
} /* Verbleibende Jobs erhalten eine Priorität gemäß EDF. x/ 


Mithin erhalten m — 1 Tasks mit der höchsten Auslastung die höchste Priorität, 
wenn ihre Auslastung größer ist als 0,5. 


Theorem 6.8: Algorithmus fpEDF hat eine Auslastungsschranke von mindestens 
1 
a 
Nach dem folgenden Theorem ist dies die beste Schranke, die wir erwarten 
können. 


Theorem 6.9: Kein Scheduling-Algorithmus mit festen Job-Prioritäten für m Pro- 
m+1 


zessoren hat eine Auslastungsschranke größer als 7. 

Der Beweis beider Theoreme kann bei Baruah [38] nachgelesen werden. Wie 
im Fall von partitioniertem Scheduling sind stärkere Schranken möglich, wenn die 
größte Auslastung bekannt ist. 
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Eine ähnliche Idee wird im EDF(k)-Scheduling-Algorithmus benutzt. Bei diesem 
Algorithmus erhalten k Tasks der höchsten Auslastung die höchste Priorität, wobei 
bei Auslastungsgleichheit beliebig entschieden wird. Alle anderen Tasks werden 
nach EDF eingeplant. 


Theorem 6.10: Seit ein sporadisches Task-System mit impliziten Deadlines. EDF(k) 
wird t auf m homogenen Prozessoren einplanen, wobei 


an 


m=(k-14| = (6.32) 


ist und U(t**)) ist die Auslastung für die Task-Menge abzüglich der ersten k Tasks. 


Auch fiir dieses Theorem kann der Beweis bei Baruah [38] gefunden werden. 


EDZL-Scheduling 


G-EDF kann Deadlines für Task-Mengen verpassen, für die ein Schedule möglich 
wäre. Wir können G-EDF verbessern, indem wir auch den Schlupf betrachten: der 
EDZL-Algorithmus benutzt G-EDF, sofern der Schlupf größer ist als Null (siehe Ba- 
ruah et al. [38], Kapitel 20). Wenn der Schlupf eines Jobs allerdings Null wird, dann 
wird die Priorität dieses Jobs auf die höchste Priorität unter allen Jobs angehoben, 
einschließlich der gerade ausgeführten Jobs. 


Beispiel 6.13: Wir betrachten das Beispiel in Abb. 6.23, welches von I. Puaut über- 
nommen wurde [461]. Die Parameter in diesem Beispiel sind: n = 3, m = 2, 
T; = T) = T3 = 3 und C = Cy = C3 = 2. Aus der Abb. 6.23 (links) geht hervor, 
dass G-EDF für diese Parameter die Deadlines fiir tz zu den Zeiten t = 3n mit 
n = 1,2,3,... verpasst. Aus Abb. 6.23 (rechts) kann gesehen werden, dass EDZL 


Abb. 6.23 G-EDF: links: verpasste Deadlines; rechts: Verbesserung durch EDZL 


dagegen die Deadlines einhält. Die Details des Verhaltens hängen dabei etwas von 
der Prozessor-Zuordnung ab, die EDZL vornimmt. V 
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Choi et al. [102] haben gezeigt, dass EDZL in jedem Fall besser ist als EDF. 
Informell kann das wie folgt gezeigt werden’: Angenommen, S ist ein EDF-Schedule 
und S’ ist ein EDZL-Schedule für dieselbe Task-Menge. Wenn ein Job zur Zeit t 
in EDZL eingeplant ist, aber nicht in EDF, dann verpasst er die Deadline in EDF, 
aber nicht in EDZL. Das Schedule bleibt dasselbe, wenn beide Strategien den Job 
einplanen. Damit gilt für den ersten Zeitpunkt, an dem S von S’ verschieden ist, das 
Folgende: 


e entweder EDZL bleibt möglich, aber EDF nicht oder 
e EDZL und EDF liefern kein Schedule. 


Daher ist EDZL in jedem Fall besser als EDF. Piao et al. [452] haben die folgende 
Auslastungsschranke fiir EDZL nachgewiesen 


1 
2 (6.33) 


6.3.4 Globales Scheduling für feste Task-Prioritäten 


Globales Rate-Monotonic Scheduling 


Ähnlich wie wir EDF zu G-EDF erweitern, können wir auch RMS zu einem Ver- 
fahren für das Multiprozessor-Scheduling, genannt G-RM, erweitern. Dabei gibt es 
für G-RM eine Anomalie bezüglich der Abschwächung von Anforderungen: 


Lemma 6.4: Bei G-RM kann es Fälle geben, in denen ein Schedule für ein bestimm- 
tes Task-System existiert, aber in denen es kein Schedule gibt, wenn wir Perioden 
verlängern. 


Beweis: Wir beweisen die Existenz dieser Anomalie durch ein Beispiel: Wir be- 
trachten ein Task-System mit den Parametern m = 2, n = 3, T = 3, CG = 2, Rn = 4, 
Cy = 2, T3 = 12 und C; = 7. Abb. 6.24 zeigt das dafür mit G-RM erzeugte Schedule. 


Abb. 6.24 Mit G-RM erzeugtes Schedule 


7 Der Hinweis auf diese informelle Erklärung stammt von J.J. Chen, TU Dortmund. 
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Wir verpassen die Deadline für T3, wenn wir die Periode von rı auf 7, = 4 verlängern 
(siehe Abb. 6.25). 


Abb. 6.25 Mit G-RM erzeugtes Schedule verpasst Deadline beit = 12 


Dieses un-intuitive Ergebnis macht Beweise und Beispiele komplizierter als im 
Einzelprozessor-Fall. o 


Das Theorem 6.4 vom kritischen Zeitpunkt für Einzelprozessoren (siehe Seite 341) 
gilt ebenfalls nicht für Multiprozessoren. 
Für G-RM wurde die folgende Auslastungsgrenze bewiesen [94]: 


Theorem 6.11: Ein periodisches oder sporadisches Task-System t mit impliziten 
Deadlines mit der Auslastung 


Usum < zu = Umax(T)) ate Umax(T) (6.34) 


kann mit G-RM erfolgreich auf einem homogenen m-Prozessorsystem (mit Einheits- 
geschwindigkeit) eingeplant werden [50]. 


G-RM leidet ebenfalls unter dem Dhall-Effekt: In Gleichung (6.34) ist zu sehen, 
dass Usym sich Null annähert, wenn Umax gegen Eins geht. Wie G-EDF kann der 
Algorithmus die Verfügbarkeit mehrerer Prozessoren nicht voll ausschöpfen. 

Daher wurde der Algorithmus RM-US(£) mit einer Schwelle € vorgeschlagen, 
wobei US für utilization threshold steht. Gegeben sei ein sporadisches Task-System 
mit impliziten Deadlines, wobei die Tasks T = {7ı,...7„} gemäß einer nicht-auf- 
steigenden Reihenfolge der Auslastungen u; sortiert seien. Bis zu (m — 1) Tasks mit 
einer hohen Auslastung sollen auf bis zu m — 1 identischen Prozessoren eingeplant 
werden. Die verbleibenden Prozessoren dienen der Ausführung der verbliebenen 
Tasks. RM-US(£) arbeitet wie folgt: 


for (i=1; i< m-—1; i++) { 
if (u; > £) Ti wird die höchste Priorität zugewiesen 
else break; 
} /x die verbleibenden Tasks werden gemäß G-RM eingeplantx*/ 


Theorem 6.12: Für m Prozessoren mit Einheitsgeschwindigkeit hat RM-US(é&) eine 
a) 


Auslastungsschranke von mindestens =s. 
(3m-2) 


Das Theorem wurde von Andersson et al. [16] bewiesen. Für 3m > 2 nähert sich 
diese Schranke dem Wert 77. Chen et al. [94] haben eine engere Schranke bewiesen. 


358 6 Abbildung von Anwendungen 


RMZL-Scheduling 


Fiir bestimmte Task-Mengen kann G-RM Deadlines verpassen, obwohl ein Sche- 
dule existiert. Eine mögliche Verbesserung ist RMZL-Scheduling. Beim RMZL- 
Verfahren nutzen wir (G-) RM-Scheduling, solange der Schlupf größer als Null ist. 
Wir setzen aber die Priorität eines Jobs auf den höchsten Wert, wenn der Schlupf 
für einen Job Null wird. RMZL-Scheduling ist RM-Scheduling überlegen, da wir die 
Schedules nur dann ändern, wenn RM-Scheduling eine Deadline verpasst hätte [38]. 


Partitioniertes Scheduling für explizite Deadlines 


Partitioniertes Scheduling für Tasks mit expliziten Deadlines kann ähnlich erfolgen 
wie partitioniertes Scheduling für Tasks mit impliziten Deadlines, indem man das 
Sortieren nach der Auslastung ersetzt durch ein Sortieren nach der Dichte. Al- 
lerdings wird dieses Verfahren nicht empfohlen, da die Dichte in manchen Fällen 
unbeschränkt sein kann. Baruah et al. haben einen besseren Ansatz für partitioniertes 
Scheduling publiziert [33]. 


6.4 Abhängige Jobs auf homogenen Multiprozessor-Systemen 


Die Ergebnisse der vorherigen Abschnitte stellen Basiswissen dar, aber die Be- 
schränkung auf unabhängige Tasks und identische Prozessoren verhindert in vielen 
Fällen ihre Anwendung. Daher lassen wir jetzt diese Einschränkungen fallen. Zu- 
nächst geben wir die Beschränkung auf unabhängige Tasks auf. Wir konzentrieren 
uns dabei auf einige einfache Algorithmen aus dem Bereich der Entwurfsautoma- 
tisierung für elektronische Schaltungen. Sehr populär sind beispielsweise die Al- 
gorithmen As-Soon-As-Possible (ASAP)-Scheduling, As-Late-As-Possible (ALAP)- 
Scheduling, List-Scheduling (LS) und Force-Directed-Scheduling (FDS) im Bereich 
der automatischen Synthese aus einer algorithmischen Beschreibung, der so genann- 
ten High-Level-Synthese (HLS) [113]. 


6.4.1 As-Soon-As-Possible-Scheduling 


As-Soon-As-Possible-Scheduling (ASAP) versucht, unter Berücksichtigung der Rei- 
henfolgebeschränkungen alle Tasks so früh wie möglich zu starten. In der High- 
Level-Synthese werden üblicherweise nur ganzzahlige Startzeiten >O betrachtet. 
Verdrängungen sind nicht erlaubt. Die Zuordnung zu bestimmten Prozessoren er- 
folgt erst nach der Bestimmung der Startzeiten. Deshalb bietet ASAP-Scheduling 
auch nur eine Abbildung auf Task-Startzeiten: 


S:r>No (6.35) 
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Bei diesem Algorithmus setzen wir voraus, dass alle Ausfiihrungszeiten bekannt 
sind und dass diese unabhängig sind von dem Prozessor, auf dem die Tasks ausgeführt 
werden, d.h. wir nehmen an, dass die Prozessoren homogen sind. Der Algorithmus 
berücksichtigt keine Beschränkungen hinsichtlich der Anzahl der Prozessoren und 
setzt voraus, dass die benötigte Anzahl von Prozessoren zur Verfügung steht. Der 
Algorithmus arbeitet wie folgt: 


for (t=0; solange es nicht eingeplante Tasks gibt; t++) { 
t’={nicht eingeplante Tasks, deren Vorgänger beendet sind}; 
Setze die Startzeit aller Tasks in 7’ auf t; 


Beispiel 6.14: Wir nehmen an, dass der Task-Graph aus Abb. 6.26 (links) gegeben 
ist. Jeder mit i bezeichnete Knoten repräsentiert eine Task t;. Die rechte Seite der 
Abb. 6.26 enthält die von uns angenommenen Ausführungszeiten. 


Task | C; 
1 9 
2 113 
3 | 11 
4 8 
5 | 10 
6 9 
7 7 
8 5 
9 | 12 
10 7 


Abb. 6.26 Links: Task-Graph; rechts: Ausfiihrungszeiten 


Das ASAP-Scheduling wird das in Abb. 6.27 gezeigte Schedule erzeugen. 


Abb. 6.27 Links: zeitlich eingeplanter Task-Graph; rechts: Zeitachse 
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Blaue Zahlen bedeuten Startzeiten, grüne Zahlen bedeuten das jeweilige Ausfüh- 
rungsende. Tasks 72 bis Te starten alle unmittelbar, nachdem Task tT, beendet ist. 
Tasks 17 bis To starten ebenfalls sofort nachdem der letzte ihrer Vorgänger die Aus- 
führung beendet hat. Die rote Linie in Abb. 6.27 (rechts) zeigt, dass im Maximum 
fünf Prozessoren benötigt werden, da ASAP-Scheduling weder eine Grenze für die 
Anzahl der Prozessoren noch das Ziel einer ausgewogenen Prozessorbelastung be- 
rücksichtigt. V 


ASAP-Scheduling minimiert den Makespan, da alle Tasks so früh wie möglich 
ausgeführt werden. Der vorgestellte Algorithmus kann so erweitert werden, dass 
als Ausführungszeiten auch reelle Zahlen benutzt werden. ASAP-Scheduling ist von 
linearer Komplexität, vorausgesetzt wir benutzen eine intelligente Methode, um 7’ 
zu berechnen. Der Algorithmus kann auch im täglichen Leben angewandt werden: 
er entspricht der Situation, in der jede Person begierig alle Arbeiten so früh wie 
möglich startet. 


6.4.2 As-Late-As-Possible-Scheduling 


As-Late-As-Possible (ALAP)-Scheduling ist der zweite einfache Algorithmus. Beim 
ALAP-Scheduling werden alle Tasks so spät wie möglich gestartet. Der Algorithmus 
funktioniert wie folgt: 


for (t=0; solange es nicht eingeplante Tasks gibt; t--) { 
t’={alle Tasks ohne Abhängigkeit zu einer nicht eingeplanten Task}; 
Setze die Startzeit aller Tasks in 7’ auf (t - ihre Ausführungszeit); 


Schiebe alle Startzeiten so, dass die erste Task zur Zeit t=® startet. 


Der Algorithmus betrachtet zunächst die Tasks, von denen keine weitere Task 
abhängt. Es wird angenommen, dass diese Tasks zum Zeitpunkt 0 enden. Ihre Start- 
zeit wird dann aus ihrer Ausführungsdauer berechnet. Danach iteriert die Schleife 
rückwärts über Zeitschritte. Wenn ein Zeitschritt erreicht wird, zu dem eine Task 
spätestens beendet sein soll, wird die Startzeit dieser Task berechnet und die Task 
eingeplant. Nach dem Ende der Schleife werden alle Zeiten so angepasst, dass die 
erste Task zum Zeitpunkt 0 startet. Wir könnten ALAP-Scheduling auch als eine 
Variante des ASAP-Scheduling betrachten, die am „anderen” Ende des Graphen 
beginnt. 


Beispiel 6.15: Für den Task-Graphen in Abb. 6.26 würde ALAP-Scheduling das in 
Abb. 6.28 gezeigte Ergebnis generieren. Die Farbkodierung ist dieselbe wie beim 
ASAP-Beispiel. Jede Task wird so spät wie möglich beendet. Insbesondere werden 
Tasks T7 bis To erst zur Zeit 34 beendet. Tasks t4 bis T6 sind später als beim ASAP- 
Schedule abgeschlossen. Tasks 71, T2, T9 und Tio werden wie beim ASAP-Schedule 
eingeplant, denn diese Tasks bestimmen den Makespan. Wir sagen, dass die Tasks, 
welche den Makespan bestimmen, auf dem kritischen Pfad liegen. Der roten Linie 
ist zu entnehmen, dass die Lösung in Abb. 6.28 fünf Prozessoren benötigt. 
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Abb. 6.28 Links: Mit ALAP-Scheduling eingeplanter Task-Graph; rechts: Zeitachse Vv 


Auch ALAP-Scheduling kann im täglichen Leben eingesetzt werden. Es entspricht 
einer Situation, in der alle Aufgaben so lange wie möglich aufgeschoben werden. 
Beim ALAP-Schedule werden viele Prozessoren benötigt, wenn der Task-Graph 
an seinem unteren Ende breit ist. Dementsprechend fällt bei diesem Vorgehen im 
täglichen Leben zum Schluss viel Arbeit an. 


6.4.3 List-Scheduling 


Beim List-Scheduling (LS) versuchen wir, die geringe Komplexität von ASAP- und 
ASAP-Scheduling beizubehalten, aber auf die Anzahl verfügbarer Prozessoren Rück- 
sicht zu nehmen. Die Prozessoren können verschiedenen Typs sein, aber wir nehmen 
immer noch an, dass es eine Eins-zu-eins-Beziehung zwischen Tasks und Prozes- 
sortypen gibt. Somit können die Prozessoren heterogen sein, aber die kritische 
Abbildung von Tasks auf Prozessortypen wird nicht durch LS erzeugt. 

Wir nehmen an, dass wir eine Menge L von Prozessortypen haben. LS respektiert 
obere Schranken B; für die Anzahl von Prozessoren für jeden Typ / € L. 

LS setzt voraus, dass eine Prioritätsfunktion definiert ist, welche die Dringlichkeit 
angibt, mit der eine bestimmte Task t; eingeplant werden muss. Die folgenden 
Dringlichkeitsmetriken finden dabei Anwendung [528]: 


« Die Beweglichkeit (engl. mobility) ist die Differenz zwischen den Startzeiten für 
die ASAP- und ALAP-Schedules. Abb. 6.29 (links) zeigt die Mobilität für unser 
Beispiel in rot. Offenbar ist das Scheduling dringend für alle Tasks auf dem 
kritischen Pfad, denn deren Mobilität ist 0. 

e Die Anzahl an Nachfolgern ist die Anzahl von Knoten im Baum unterhalb des 
aktuellen Knotens T (siehe Abb. 6.29 (rechts)). 

e Die Pfadlänge für einen Knoten 7; ist definiert als die Länge des Pfades vom 
Startknoten 7; bis zum Endknoten des Graphen G. Die Pfadlänge ist typischer- 
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Abb. 6.29 Laufendes Beispiel: links: Mobilitat; rechts: Zahl der Nachfolger; 


weise mit der Ausführungszeit der Knoten gewichtet, vorausgesetzt, dass diese 
Information bekannt ist. In Abb. 6.30 (links) wurde die Pfadlänge eingetragen. 


LS verlangt die Kenntnis des einzuplanenden Task-Graphen, einer Abbildung 
jedes Knotens des Graphen auf den entsprechenden Ressourcentyp / € L, einer 
Prioritätsfunktion (wie eben erklärt) und der Ausführungszeit für jede Task 7; in r. 
LS versucht dann, Knoten maximaler Priorität jedem der Zeitschritte zuzuordnen, 
wobei die Randbedingungen nicht verletzt werden [528]: 


for (t=0; solange nicht eingeplante Tasks vorh.; t++) /* Zeit-Schleife */ 

for (lEL){ /* Schleife über Ressourcentypen */ 

Til = Menge der Tasks vom Typ l, die zur Zeit t noch ausgeführt werden; 
Ti = Menge der Tasks vom Typ l, die zur Zeit t starten können; 


Berechne Menge T; C7**, maximaler Priorität, sodass 


ll all S Bie /* Anzahl der Tasks < Schranke?/ 
Setze Startzeiten aller zer, auf t: s; =f; 


Beispiel 6.16: Abb. 6.30 zeigt das Ergebnis der Anwendung von List-Scheduling mit 
der Pfadlänge als Prioritätsfunktion auf unser Beispiel von Abb. 6.26. Wir nehmen 
an, dass alle Prozessoren von demselben Typ sind und wir erlauben maximal drei 
Prozessoren (Bı = 3). Zur Zeit 9 haben Tasks 12,74 und t5 den längsten Pfad und 
daher die höchste Priorität. ra beendet die Ausführung zur Zeit 17 und 73 wie auch T6 
haben unter den verbleibenden Tasks die größte Pfadlänge. Wir nehmen an, dass wir 
73 einplanen. ts beendet die Ausführung zur Zeit 19 und 76 kann gestartet werden. 
Zum Zeitpunkt 28 werden t3 und rg die Ausführung beenden, womit Prozessoren 
für 77 und rg frei werden. t7 wird zur Zeit 35 fertig gestellt, wodurch die abhängige 
Task T10 starten und zur Zeit 42 fertig gestellt sein kann. Der Abschluss erfolgt nur 
wenig später als in den ASAP- und ALAP-Schedules, obwohl nur drei Prozessoren 
zur Verfügung stehen. Für die Zuordnung zu konkreten Prozessoren bestehen noch 
Wahlmösglichkeiten. 
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Abb. 6.30 Links: Task-Graph mit Pfadlängen; rechts: Zeitachse Vv 


LS wahlt ebenso wie ASAP- und ALAP-Scheduling fiir die Tasks keine Prozes- 
soren aus, aber aufgrund des eingeschränkten Ressourcenmodells muss das auch 
nicht sein. Eine Erweiterung von LS auf reelle Zahlen als Ausfiihrungszeiten ist 
möglich. Üblicherweise erzeugt der Algorithmus gute Ergebnisse und er kann an 
verschiedene Szenarien leicht angepasst werden. Deshalb ist LS ein beliebter Sche- 
duling-Algorithmus für Tasks mit Reihenfolgebeschränkungen. 

Force-directed scheduling (FDS) ist eine weitere beliebte Heuristik für abhängige 
Tasks. FDS zielt auf eine möglichst effiziente Nutzung der Prozessoren, indem es 
versucht, die Nutzung der Prozessoren über der Zeit möglichst gut auszubalancieren. 
Details finden sich bei Paulin et al. [449]. 


6.4.4 Optimales Scheduling mit Ganzzahliger Programmierung 


Als nächstes beschreiben wir einen Ansatz, um Tasks auf verschiedenen Prozessoren 
zu verteilen, wobei die Entscheidungen auf einer mehr globalen Basis getroffen 
werden. Der Ansatz basiert auf der Ganzzahligen Linearen Programmierung (engl. 
Integer Linear Programming (ILP)) (siehe Anhang A). Auf diese Weise werden 
Randbedingungen und Zielkriterien explizit dargestellt. Wir benutzen dabei Material 
aus einer Publikation von Coscun et al. [112]. 

ILP-Modelle bestehen aus einer linearen Kostenfunktion und einer Menge an 
linearen Randbedingungen. Im Modell werden wir die folgenden Variablen benutzen: 


Xi,k : = 1 wenn Task 7; auf Prozessor nr, ausgeführt wird und =0 sonst 
Si : Startzeit von Task 7; 


fi : Fertigstellungszeit von Task 7; 


N 


į : Ausführungsdauer von Task 7; 


bi j : = 1 wenn Task 7; vor t; auf demselben Prozessor ausgeführt wird, sonst =0 
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Wir nehmen an, dass unser Task-Graph G = (T,E) einen gemeinsamen Aus- 
gangsknoten Texit besitzt. Wir fügen einen solchen Knoten künstlich hinzu, wenn 
es ihn zunächst nicht geben sollte. Die Fertigstellungszeit dieses Knotens entspricht 
dem Makespan M Smax. Wir können diese Zeit als unsere zu minimierende Kos- 
tenfunktion verwenden. Daher können wir das Zielkriterium wie folgt ausdrücken: 


Min frexit) (6.36) 


Nun sehen wir uns die Randbedingungen an. Erstens miissen wir verlangen, dass 
jede Task auf einem Prozessor ausgefiihrt wird: 


Wet: >) x= (6.37) 
keil..m} 


Zweitens sind die verschiedenen Zeiten über die folgenden Gleichungen miteinander 
verbunden: 


\ner:fi=si+G (6.38) 


Drittens können die folgenden Gleichungen benutzt werden, um die Reihenfolgebe- 
dingungen einzuhalten: 


Wnt) €E:s;- fi >0 (6.39) 


Viertens miissen wir bei einem Einzelprozessor den Code in einer Reihenfolge 
ausführen, der durch die Variable b; ; bestimmt wird: 


V(t, Tj) : fi < Sj falls bij =1 (6.40) 


Fünftens müssen wir berücksichtigen, dass ein Prozessor zu einer bestimmten Zeit 
nur eine Task ausführen kann. Dies kann auf die folgende Weise ausgedrückt werden: 


V(Ti, Tj) t bij + bjii = | falls 3 Tk : Xi,k = Xj,k = 1 (6.41) 


Die Gleichungen (6.40) und (6.41) können auf die lineare Form gebracht werden, 
die für ein ILP-Modell erforderlich ist [112]. 

Das entstehende ILP-Modell kann einem ILP-Lösungsverfahren übergeben wer- 
den. ILP-Modelle, wie das vorgestellte, haben den Vorteil einer präzisen Model- 
lierung des Entwurfsproblems und der Zielfunktion. Sie erlauben globale Opti- 
mierungen mittels mathematischer Methoden und gehen damit über die imperative 
Programmierung hinaus. 

Das ILP-Problem ist NP-hart. Daher können die Laufzeiten von ILP-Lösungs- 
verfahren groß werden. Allerdings hat es in den letzten Jahren große Fortschritte 
beim der Konzeption von ILP-Lösungsverfahren gegeben. Daher können moderat 
große Probleme in akzeptabler Zeit gelöst werden. Aufgrund ihrer Komplexität 
können sie aber nicht für wirklich große Probleme benutzt werden, weil für diese die 
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Laufzeiten evtl. unannehmbar groß werden. Für mittelgroße Probleme ist dennoch 
eine exakte Optimierung möglich und bei größeren Problemen können diese Modelle 
als Ausgangsbasis für Heuristiken eingesetzt werden. 


6.5 Abhängige Jobs auf heterogenen Multiprozessoren 
6.5.1 Problem-Beschreibung 


Nach dem Streichen der Beschränkung auf unabhängige Tasks wollen wir nunmehr 
auch die Beschränkung auf homogene Prozessoren aufheben. Wir nehmen an, dass 
die Ausführungszeiten auf den verschiedenen Prozessoren unserer Ausführungs- 
plattform x = {m1,...,%m} nicht miteinander in einer Beziehung stehen. Gemäß 
der Klassifikation von Pinedo betrachten wir damit den Fall (R„|r;, prec,....|...). 
Dies erlaubt es uns, Plattformen mit einer Mischung von Ausführungseinheiten zu 
modellieren, einschließlich FPGAs und GPUs. 

Die Theorie der resultierenden Scheduling-Probleme ist nicht umfangreich un- 
tersucht worden. Folglich schreiben Baruah et al. im Kapitel 22 ihres Buchs [38]: 
„although unrelated multiprocessors are becoming increasingly more important in 
real-time systems implementation, the resulting scheduling theoretic study of such 
systems is, relatively speaking, still in its infancy.” Einige erste Ergebnisse wurden 
im Buch von Baruah et al. vorgestellt, aber wir ziehen es hier vor, Methoden aus der 
Entwurfsautomatisierung von Schaltkreisen vorzustellen. Diese Methoden sind in 
der Lage, realistische Entwurfsaufgaben zu lösen, unter Verzicht auf eine Garantie 
der Optimalität. 


6.5.2 Statisches Scheduling mit lokalen Heuristiken 


Nachfolgend werden wir den Heterogeneous-Earliest-Finish-Time (HEFT)- und den 
Critical-Path-On-a-Processor (CPOP)-Algorithmus beschreiben. Diese beiden Al- 
gorithmen bilden Tasks eines Task-Graphen auf ein heterogenes Multiprozessor- 
System 7 = {71,...,%m} ab [545]. Diese beiden Algorithmen sind Standard-Beispiele 
für schnelle Algorithmen. In gewisser Weise erweitern sie ASAP- und ALAP- 
Scheduling auf heterogene Prozessoren. Wir benutzen die nachfolgend beschriebene 
Notation: 


e Wir nehmen an, dass der Task-Graph einen gemeinsamen Eingangsknoten Tentry 
besitzt. Sollte ein solcher Knoten anfänglich nicht vorhanden sein, so fügen wir 
einen Knoten mit einer Ausführungszeit von 0 und ohne Kommunikationsanfor- 
derungen künstlich hinzu. 

e Wir nehmen an, dass der Task-Graph einen gemeinsamen Ausgangsknoten Texir 
besitzt. Sollte ein solcher Knoten anfänglich nicht vorhanden sein, so fügen wir 
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einen Knoten mit einer Ausführungszeit von 0 und ohne Kommunikationsanfor- 
derungen kiinstlich hinzu. 

e Die Matrix C = (ci k) bezeichnet die Ausfiihrungszeit von Task 7; auf Prozessor 
Tk. 

¢ Die Matrix B = (bk, 1) bezeichnet die Kommunikationsbandbreite für die Kom- 
munikation vom Prozessor zz; zum Prozessor 77. 

e Die Matrix data = (data; j) kennzeichnet das Datenvolumen, das von Task 7; 
nach Task 7; übertragen werden muss. 

e Der Vektor x = (kr) enthält die Initialisierungskosten für Kommunikation auf 
dem Prozessor 7x. 

e Die Matrix H = (hi ;,x,ı) repräsentiert die Kommunikationskosten für die Kom- 
munikation von der Task 7; zur Task 7; unter der Annahme, dass die Task 7; 
auf den Prozessor 7 abgebildet wird und dass die Task t; auf den Prozessor 7 
abgebildet wird®. 

In unserer Notation werden wir generell den Index i für den Ausgangsknoten bei 
Präzedenzrelationen bzw. Datenabhängigkeiten verwenden und den Index k für 
den Prozessor, auf den dieser abgebildet wird. 

In ähnlicher Weise steht j für das Ziel bei Präzedenzrelationen und / für den 
dazugehörigen Prozessor. 

e Für eine Abbildung auf Prozessoren zg und 7; stellt A; ;,x,ı die Kommunikations- 
kosten von Task 7; zu Task 7; dar: 


datai j 


hi jki = Kk + falls k #1 (6.42) 


k,l 
= 0 falls k = l (6.43) 


e Die durchschnittlichen Kommunikationskosten sind definiert als 


datai j 
en (6.44) 


Dabei ist x die durchschnittliche Zeit für das Starten der Kommunikation und B 
ist die durchschnittliche Kommunikationsbandbreite. 
e Die früheste Startzeit für Task 7; auf Prozessor x für ein partielles Schedule ist 


SelTi, nk) mit Yk : SelTentry Ak) = 0 (6.45) 


e Die früheste Fertigstellungszeit für Task t; auf Prozessor 7% für ein gegebenes 
partielles Schedule heißt 


felti, Tk) mit fe(Tentry, nk) = Centry,k (6.46) 


e Auf der Basis der Entscheidung, Task 7; auf Prozessor rk abzubilden, können die 
tatsächliche Startzeit s(7;,7,) und die tatsächliche Fertigstellungszeit f(7;, 7) 
berechnet werden. 


8 Die Indices k und / sind in der ursprünglichen Veröffentlichung nicht explizit vorhanden. 
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Se(Tj, 71) und fe(Tj, Tı) können aus einem partiellen Schedule iterativ wie folgt 
berechnet werden: 


Se(Tj, T1) = max {avail(]), MAXz; epred(r;)(f (Ti) + hij} (6.47) 
Felt; 71) = Cjl + Se(Tj, 71) (6.48) 


wobei pred(r;) die Menge der unmittelbaren Vorgänger-Tasks von Task 7; ist, 
k ist der Prozessor, auf den Task 7; im partiellen Schedule abgebildet ist und 
avail(l) ist die Zeit, zu der Prozessor 7; die Ausführung der letzten Task beendet 
hat. Der max-Ausdruck im inneren Term bestimmt die Zeit, zu der alle Daten, 
die von T; benötigt werden, beim Prozessor zz; angekommen sind. 

« Als Zielkriterium nehmen wir den Makespan. Dieser wird aus dem Abschluss 
der Berechnungen auf dem exit-Knoten bestimmt: 


M Smax = f (Texit) (6.49) 


e Die durchschnittliche Ausführungszeit c; ist das Mittel der Ausführungszeiten 
ci,x über alle Prozessoren k. 

e Der Aufwärts-Rang (engl. upward rank) rank,,(7;) einer Task 7; ist die Länge des 
kritischen Pfades vom exit-Knoten bis zum Knoten 7; (diesen einschlieBend): 


ranky(Texit) = Cexit (6.50) 
rank,(t) = cj; + max his + rank, (t;)) (6.51) 


TjEesucc(Ti 


Dabei ist succ(T;) die Menge unmittelbaren Nachfolger von t; im Task-Graphen. 
e Der Abwärts-Rang (engl. downward rank) rankg(z;) ist die Länge des kritischen 
Pfades vom start-Knoten bis zum Task-Knoten 7; (ohne 7; selbst): 


ranka(Tentry) = 0 (6.52) 


rankg(tj) = max aa +O + hi.) (6.53) 


Tj €pred(tj 
Der HEFT-Algorithmus lässt sich wie folgt beschreiben: 


Setze die Berechnungs- und die Kommunikationskosten auf ihre Mittelwerte; 
Berechne rank,(T;)Vr; (Durchlauf nach oben, startend bei Texir); 
Sortiere Tasks in nicht-aufsteigender Folge von rank,,-Werten; 
while es gibt ungeplante Tasks in der Liste do { 
Wähle die erste Task 7; in der Liste für das Scheduling; 

for jeden Prozessor mz, en { 

Berechne fe(Ti, nk) mit Einfüge-orientiertem Scheduling? ; 

} 
Weise Task t; dem Prozessor mx zu, der fe(t;, nk) minimiert; 


} 


° Der Algorithmus sucht eine ausreichend große Lücke unter den bereits eingeplanten Tasks derart, 
dass eine Zuweisung zu dieser Lücke die Reihenfolgebeschränkungen einhält. 
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Beispiel 6.17: Wir nehmen an, dass die Ausfiihrungszeiten durch die Tabelle in Abb. 
6.31 (links) gegeben sind. Für jede Task wurden die Ausführungszeiten in Abb. 6.26 
(rechts) als Minimum über die drei Prozessoren gewählt. 
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Abb. 6.31 Links: Ausfiihrungszeiten; Mitte: Ergebnisse fiir HEFT; rechts: Ergebnisse fiir CPOP 


Abb. 6.31 (Mitte) zeigt das Schedule, welches HEFT fiir den DAG in Abb. 6.26 
(links) erzeugt. Es ist kein kurzes Schedule wie beim ASAP/ALAP-Scheduling, da 
wir jetzt Reihenfolge- und Ressourcenbeschränkungen beachten. Vv 


Der CPOP-Algorithmus konzentriert sich auf den kritischen Pfad im DAG und er 
benutzt verschiedene Task-Prioritäten und verschiedene Strategien für die Zuordnung 
von Prozessoren. Der CPOP-Algorithmus arbeitet wie folgt: 


Setze die Berechnungs- und die Kommunikationskosten auf ihre Mittelwerte;; 
Berechne Vi : rank,,(t;) und ranka(T;); 

Berechne Vi: priority(t;) = rankg(t;) + rank,(7;); 

|CP| = priority(tentry); /* Länge des kritischen Pfades */ 

SETcp = {Tentry}, mit SETcp: Menge der Tasks auf dem kritischen Pfad; 
Ti =Tentry; 

while 7; ist nicht der exit-Task { 


Wähle 7; € succ(t;), mit priority(t;) == |CP]. 
SETcp =SETcp U ke: 
ie, 

}; 


Wähle Prozessor mcp, der Ausführungszeit auf kritischem Pfad minimiert; 
Initialisiere eine Warteschlange mit der entry-Task; 
while es gibt eine ungeplante Task in der Warteschlange { 

Wähle die Task der höchsten Priorität Tt; aus der Warteschlange; 

if t; € SETcp {weise t; Prozessor ncp zu} 

else {weise Task 7; dem Prozessor zu, der fe(Ti, nk) minimiert}; 
Aktualisiere Warteschlange mit Nachfolgern von T; wenn sie bereit werden; 


} 


Beispiel 6.18: Abb. 6.31 (rechts) zeigt das mit CPOP erzeugte Schedule . Vv 
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HEFT und CPOP sind relativ schnelle und einfache Algorithmen. Diese Algo- 
rithmen nutzen verschiedene Näherungen (wie z.B. durchschnittliche Kommunika- 
tionskosten) und Heuristiken. HEFT und CPOP wurden für dieses Buch ausgewählt, 
um Schwierigkeiten mit Scheduling-Algorithmen für heterogene Prozessoren zu de- 
monstrieren. Allerdings ist es möglich, im Vergleich zu diesen beiden Algorithmen 
bessere Ergebnisse zu erzielen. Beispielsweise haben Kim et al. [295] komplexere 
Algorithmen beschrieben, die bessere Ergebisse liefern. Castrillon et al. [86] haben 
ein Scheduling für KPNs entwickelt, welches ebenfalls den Makespan minimieren 
soll. 


6.5.3 Statisches Scheduling mit Ganzzahliger Programmierung 


Die Ganzzahlige Lineare Programmierung kann auch auf heterogene Prozessoren 
angewandt werden. Ein Ansatz hierzu wurde von Maculan et al. [362] publiziert. 
Sehr wichtig ist, dass dabei prozessorabhängige Ausführungszeiten betrachtet wer- 
den. Allerdings bedürfen die gezeigten Gleichungen noch einiger Überarbeitungen, 
bevor sie vollständig die Form eines Ganzzahligen Optimierungsproblems haben. 
Weiterhin ist es auch möglich, Techniken der High-Level-Synthese [43, 315] zu 
adaptieren. 

In vielen der Publikationen werden Optimierungen für eine einzelne Metrik (ein 
Zielkriterium) betrachtet. Im allgemeinen sollten mehrere Zielkriterien betrachtet 
werden. Beispielsweise beschreiben Fard et al. [162] einen Algorithmus, der mehrere 
Zielkriterien betrachtet. 


6.5.4 Statisches Scheduling mit Evolutionären Algorithmen 


Verfahren auf der Basis der Ganzzahligen Programmierung leiden unter potentiell 
großen Rechenzeiten. In vielen Fällen erlauben evolutionäre Algorithmen bei ak- 
zeptablen Rechenzeiten eine bessere Optimierung. Wir werden dies am Beispiel der 
Distributed Operation Layer (DOL)-Werkzeuge von der ETH Zürich zeigen [537]. 
Diese Werkzeuge beinhalten folgende Funktionen: 


e Automatische Selektion von Prozessorarchitekturen: die Prozessortypen kön- 
nen vollständig heterogen sein. Mögliche Optionen sind Standard-Prozessoren, 
Mikrocontroller, DSP-Prozessoren, FPGAs usw. 

e Automatische Selektion von Kommunikationstechniken: verschiedene Ver- 
bindungsschemata wie zentrale Busse, hierarchische Busse, Ringe usw. sind rea- 
lisierbar. 

e Automatische Selektion von Scheduling und Arbitrierung: die in DOL verfüg- 
baren Werkzeuge zur Erkundung des Entwurfsraumes wählen automatisch zwi- 
schen Rate Monotonic Scheduling, EDF, TDMA- und prioritätsbasierten Sche- 
mata. 
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DOL erwartet eine Menge von 
Tasks und zugehörigen Anwen- p pp 
dungsfällen als Eingabe. Die Aus- 
gabe beschreibt die Ausführungs- 


plattform, die Abbildung von Tasks Kommunikatiori< © 


auf Prozessoren zusammen mit den 
Task-Schedules. Diese Ausgabe soll 

bestimmte Beschränkungen (wie 
Speichergröße und Zeitschranken) 

einhalten und vorgegebene Ziele Abb. 6.32 DO 
(wie Größe, Energie usw.) mini- 


6 Abbildung von Anwendungen 


N, 
N, 


L Problem-Graph 


mieren. Anwendungen werden als sogenannte Problem-Graphen dargestellt, die im 
Wesentlichen spezielle Task-Graphen sind. In Abb. 6.32 ist ein einfacher DOL- 


Problemgraph zu sehen. Dieser Graph modelliert 
und Kommunikation (Knoten 5, 6, 7). 


Berechnungen (Knoten 1,2, 3, 4) 


Zusätzlich werden mögliche Ausführungsplattformen als sogenannte Architek- 
turgraphen dargestellt. Abb. 6.33 zeigt eine einfache Hardwareplattform und ihren 
Architekturgraphen. Es gibt einen RISC-Prozessor und zwei Hardwaremodule. Auch 
hier wird die Kommunikation (mittels Bus1 und Bus2) explizit modelliert. 


Abb. 6.33 DOL AWMI RISC HWM1 
Architekturgraph 
RISC 
Bus2 Bus1 Bus2 
Bus HWM2 
HWM2 


Der Problemgraph und der Architekturgraph 
werden im Spezifikationsgraphen verbunden. In 
Abb. 6.34 ist ein DOL-Spezifikationsgraph dar- 
gestellt. Ein solcher Spezifikationsgraph besteht 
aus dem Problemgraphen und dem Architektur- 
graphen. Kanten zwischen den beiden Teilgra- 
phen stellen mögliche Implementierungen dar. 
Beispielsweise kann die Berechnung 1 nur auf 
dem RISC-Prozessor, Berechnung 3 auf dem 
RISC-Prozessor oder auf HWM1 realisiert wer- 
den. Kommunikation 5 kann auf dem Bus Bus1 
oder — wenn die Berechnungen 1 und 3 beide auf 
den Prozessor abgebildet werden — lokal im Pro- 
zessor stattfinden. Kommunikation 6 kann auf den 
in HWM2 stattfinden. 


RISC 


Bus1 


HWM1 


Bus2 


HWM2 


Abb. 6.34 DOL Spezifikationsgraph 


Bussen Bus1 bzw. Bus2 oder lokal 
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Insgesamt werden Implementierungen durch ein Tripel beschrieben: 


« Eine Allokation A: A ist eine Teilmenge des Architekturgraphen, die für einen 
bestimmten Entwurf reservierte (ausgewählte) Hardwarekomponenten darstellt. 

« Eine Bindung b: eine ausgewählte Teilmenge der Kanten zwischen Spezifika- 
tion und Architektur kennzeichnet eine Relation zwischen diesen beiden. Die 
ausgewählten Kannten werden als Bindung bezeichnet. 

« Einen Zeitplan (Schedule) S: S weist jedem Knoten 7; im Problemgraphen seine 
Startzeit zu. 


Beispiel 6.19: Abb. 6.35 zeigt, wie 


Aih RISC 

die Spezifikation aus Abb. 6.34 in BR 

eine Implementierung umgesetzt wer- A A oust 

den kann. HWM2 und der Bus2 wer- \\ HWMI 

den nicht benutzt und sind nicht in N 

der Menge A enthalten. Eine Teil- A 

menge b der Kanten wurde für die HWM1 

Abbildung ausgewählt. Die Knoten RISC | 

1, 2, 3, 5 wurden alle auf den RISC- ! TEREN 
- JHWM2 | 


Prozessor abgebildet, wodurch die 
Kommunikation 5 eine rein lokale 
Kommunikation wird. Knoten 4 ist 
auf HWM1 abgebildet und er kom- 
muniziert über den Bus Bus1. Der Ablaufplan S besagt, dass Berechnung 1 zur Zeit 
0 startet, Kommunikation 5 und Berechnung 2 beginnen zur Zeit 1, Berechnung 3 
und Kommunikation 6 fangen zur Zeit 21 an, Kommunikation 7 beginnt zur Zeit 29 
und Berechnung 4 startet zum Zeitpunkt 30. V 


Abb. 6.35 DOL Implementierung 


DOL erzeugt Implementierungen mit Hilfe evolutionärer Algorithmen [31, 30, 
107]. In solchen Algorithmen werden Lösungen durch Folgen von Werten in den 
Chromosomen von „Individuen” dargestellt. Mit evolutionären Algorithmen lassen 
sich neue Lösungsmengen aus existierenden Mengen von Lösungen ableiten. Die 
Ableitung basiert dabei auf evolutionären Operatoren wie Mutation, Selektion und 
Rekombination. Die Auswahl neuer Lösungsmengen erfolgt auf der Grundlage von 
Eignungswerten (engl. fitness values). Evolutionäre Algorithmen können komplexe 
Optimierungsprobleme lösen, bei denen andere Arten von Algorithmen versagen. 
Es ist nicht leicht, geeignete Kodierungen von Lösungen in Chromosomen zu finden. 
Einerseits sollte die Dekodierung nicht zu viel Rechenzeit benötigen, andererseits 
müssen wir die Situation nach den evolutionären Transformationen berücksichtigen. 
Diese Transformationen könnten nicht realisierbare Lösungen erzeugen, wenn die 
Kodierungen nicht sorgfältig gewählt werden. 

In DOL kodieren die Chromosomen die Auswahl (Allokation) von Hardware und 
die Bindungen. Zur Berechnung der Fitness einer Lösung müssen Allokationen und 
Bindungen aus den Individuen dekodiert werden (siehe Abb. 6.36). 
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Individuum 
Evolutionarer ; > Dekodiere Allokation 
Algorithmus Alekatien Į 
1. Selektion Bindung Z| Dekodiere Bindung 
2. Rekombination 
3. Mutation V 
Chromosom = kodierte slr IS) 
Allokation + Bindung Randbedingungen Lösun 
\ (Implementierung) 
» fitness Fitness-Bewertung 


Abb. 6.36 Dekodieren der Lösungen aus den Chromosomen von Individuen 


Bei DOL werden Zeitpläne nicht in den Chromosomen kodiert. Vielmehr werden 
sie aus der Allokation und Bindung abgeleitet. Dadurch wird das Überfrachten der 
evolutionären Algorithmen mit Scheduling-Entscheidungen vermieden. Sobald der 
Zeitplan berechnet wurde, kann die Eignung der Lösungen evaluiert werden. 

Die gesamte Architektur von DOL ist in Abb. 6.37 dargestellt. 


System-Architektur, 
Performanz-Werte 


Task-Graph, 
MOSES use cases, x EXPO Explorations- SPEA2 
Ressourcen Zyklus 
Wahl von „guten“ 
Architekturen 


Abb. 6.37 DOL-Werkzeug 


Zu Beginn werden der Task-Graph, Anwendungsfälle und die verfügbaren Res- 
sourcen definiert. Dazu dient ein spezieller Editor namens MOSES. Diese Anfangs- 
informationen werden durch das Evaluations-Framework EXPO bewertet. Durch 
EXPO berechnete Performanzwerte werden dann an SPEA2 weitergeleitet und dort 
durch evolutionäre Algorithmen verarbeitet. SPEA2 wählt gute Architekturen. Diese 
werden zur Bewertung an EXPO weitergeleitet. Die Bewertungsergebnisse werden 
wieder an SPEA2 geschickt, um erneut zu optimieren. Dieses Wechselspiel zwi- 
schen EXPO und SPEA2 findet so lange statt, bis gute Lösungen gefunden wurden. 
Die Auswahl der Lösungen erfolgt nach dem Prinzip der Pareto-Optimalität. Der 
Entwickler erhält eine Menge Pareto-optimaler Entwürfe und kann dann zwischen 
den verschiedenen Zielen abwägen. 
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Beispiel 6.20: In Abb. 6.38 ist die sich ergebende Pareto-Front graphisch dargestellt. 
Die Trade-Offs zwischen der Performanz von zwei Netzwerken und möglichen Ein- 
sparungen sind zu erkennen. 


Einsparungen 


~ Performanz für 
Netzwerk 2 


Performanz, für 
Netzwerk 1 


Abb. 6.38 Pareto-Front von Lösungen für ein Entwurfsproblem, QETHZ Vv 


Holzkamp hat eine Variante von DOL entwickelt, die sich auf die Optimierung der 
Speicherzuordnung konzentriert [221]. Evolutionäre Algorithmen sind eine Stan- 
dardtechnik zur Lösung fortgeschrittener Scheduling-Probleme (d.h. jenseits der 
durch HEFT und CPOP gelösten Probleme) geworden. 

Die Funktionalität von SystemCodesigner [286] ähnelt der von DOL. Die Systeme 
unterscheiden sich aber darin, wie Spezifikationen beschrieben werden (hier kann 
SystemC verwendet werden) und wie die Optimierungen durchgeführt werden. Die 
Abbildung von Anwendungen wird als ILP-Modell dargestellt. Eine erste Lösung 
wird mit einem ILP-Optimierer erstellt. Diese Lösung wird dann durch den Einsatz 
evolutionärer Algorithmen verbessert!°. 

Daedalus [423] beinhaltet automatische Parallelisierung. Dazu werden sequenzi- 
elle Algorithmen auf Kahn-Prozessnetzwerke abgebildet. Die Entwurfsraumerkun- 
dung findet dann unter Verwendung von Kahn-Prozessnetzwerken als Zwischendar- 
stellung statt. 

Andere Ansätze beginnen mit einem gegebenen Task-Graphen und bilden auf 
eine feste Architektur ab. Beispielsweise bildet Ruggiero Anwendungen auf Cell- 
Prozessoren ab [475]. Das HOPES-System kann auf verschiedene Prozessoren 


10 Eine neuere Version verwendet dafür einen sogenannten satisfiability solver (SAT), der Erfüll- 
barkeitsprobleme der Prädikatenlogik lösen kann. 
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abbilden [195], dabei verwendet es Berechnungsmodelle, die von den Ptolemy- 
Werkzeugen unterstiitzt werden. Einige Werkzeuge beriicksichtigen zudem weitere 
Ziele. So behandelt Xu zum Beispiel die Optimierung der zuverlässigen Lebensdau- 
er des resultierenden Systems [605]. Simunic betrachtet in ihren Arbeiten zusätzlich 
eine Temperaturanalyse und versucht, die Entstehung zu heißer Stellen auf dem MP- 
SoC zu vermeiden [492]. Weitere Arbeiten finden sich bei Popovici et al. [457]. Er 
verwendet verschiedene Ebenen der Modellierung unter Verwendung der Sprachen 
Simulink und SystemC. 

Ansätze zur automatischen Parallelisierung für festgelegte Architekturen finden 
sich bei Arbeiten an der Universität von Edinburgh [168]. Die MAPS-Werkzeu- 
ge [88] verbinden automatische Parallelisierung mit einer eingeschränkten Form 
der Entwurfsraumerkundung. Cordes [110] hat eine automatische Parallelisierung 
für Mehrkern-Systeme entwickelt, die ein Kostenmodell auf einer hohen Ebene 
benutzt. Eine automatische Parallelisierung wurde auch von Neugebauer et al. [417] 
entwickelt. Sie wurde zur Optimierung eines innovativen Sensors für Bio-Viren, 
einem cyber-physikalischen System, benutzt. 


6.5.5 Dynamisches und Hybrides Scheduling 


Beim dynamischen Scheduling erfolgt die Prozessorzuordnung zur Laufzeit und 
nicht zur Entwurfszeit. Dynamisches Scheduling hat eine Reihe von Vorteilen [493]: 


e Anpassbarkeit an die verfügbaren Ressourcen: Dynamisches Scheduling kann 
sich anpassen, wenn sich die Verfügbarkeit von Ressourcen wie Energie, Spei- 
cherplatz oder Kommunikationsbandbreite ändert. 

e Anpassbarkeit an sich ändernde Ressourcenanforderungen: Änderungen be- 
züglich der Anforderungen der Anwendungen (wie z.B. ein wachsender Speicher- 
bedarf) sind leichter zu integrieren, wenn das Scheduling dynamisch ist. 

« Elastizität in Bezug auf Defekte: Ressourcendefekte können mit einem dyna- 
mischen Scheduling leichter berücksichtigt werden. 

« Benutzung von nicht echtzeitfähigen Plattformen: Dynamisches Scheduling ist 
bei nicht echtzeitfähigen Rechnern der Standard. Daher können Techniken dieser 
Plattformen eingesetzt werden, was den Entwicklungsaufwand reduziert. 


Allerdings gibt es auch Nachteile: 


e Fehlende Garantien für das Echtzeitverhalten: in einem vollständig dynami- 
schem Schedule ist es schwer, wenn nicht unmöglich, Garantien für das Einhalten 
von Echtzeitbedingungen zu geben. 

e Laufzeit-Overhead: dynamisches Scheduling erfordert Rechenzeit, um Entschei- 
dungen zu treffen. Daher müssen komplexe Scheduling-Techniken vermieden 
werden. 

e Beschränktes Wissen: zur Laufzeit ist üblicherweise nur ein sehr begrenztes 
Wissen über das Task-System und seine Parameter bekannt. 
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Es gibt zwei Ansätze für ein dynamisches Scheduling: ein vollständig dynami- 
sches Scheduling (engl. on-the-fly mapping) und ein hybrides Scheduling, bei dem 
Ergebnisse der Entwurfsraumexploration ausgenutzt werden. 

Einen Überblick über 25 verschiedene Ansätze für ein vollständig dynamisches 
Scheduling haben Singh et al. [493] veröffentlicht. Diese Art des Schedulings kommt 
den Nicht-Echtzeitsystemen am nächsten. 

Hybride Scheduling-Techniken benutzen Ergebnisse früherer Entwurfsraumex- 
plorationen, um die o.a. Nachteile von dynamischen Techniken auszugleichen. Bei- 
spielsweise können wir Schedules für wahrscheinliche Laufzeitszenarien vorab be- 
rechnen und dann zur Laufzeit aufgrund des aktuellen Szenarios auswählen. Singh et 
al. unterscheiden Verfahren mit mehreren Schedules, die für eine einzige Anwendung 
vorab berechnet sind, Verfahren mit mehreren Schedules für mehrere Anwendungen 
und Verfahren, welche die Zuverlässigkeit mit einbeziehen!!. Die Autoren geben 
eine Übersicht über 21 verschiedene Ansätze für die Abfolge von Analysen zur 
Entwurfszeit und Entscheidungen zur Laufzeit. 

Man könnte noch einen Schritt weiter gehen und Scheduling mit der Anwendung 
integrieren. Beispielsweise hat Kotthaus [308] ein Verfahren zur mathematischen 
Optimierung entwickelt, bei dem dies der Fall ist. In diesem Ansatz ist die Anzahl 
der Berechnungen der Zielfunktion nicht fest, sondern hängt von dem Fortschritt der 
parallelen Berechnungen auf einem Mehrkern-System ab. Eine ähnliche Integration 
ist auch für andere Anwendungen möglich. 


6.6 Aufgaben 


Die folgenden Aufgaben sollten entweder zu Hause oder während einer Anwesen- 
heitsphase nach dem flipped classroom-Konzept [376] bearbeitet werden: 


6.1: Gegeben sei eine Menge von vier Jobs. Ankunftszeiten r;, Deadlines D; und 
Rechenzeiten C; sind wie folgt: 


” Jı:rı=10, Dı=18, Cı=4 

” Jo: n=0, D>=28, O=12 

® Jz: r3=6, D3=17, C3=3 

* Ja: r4=3, D4=13, C4=6 

Erzeugen sie eine graphische Darstellung der Schedules für diese Job-Menge un- 
ter Benutzung der Earliest Deadline First und der Least Laxity-(LL-)Scheduling- 


Algorithmen! Geben Sie beim LL-Scheduling für alle Jobs beim Kontextwechsel 
den Schlupf an! Wird ein Job seine Deadline verpassen? 


6.2: Gegeben sei eine Menge von sechs Tasks 7; bis r6. Ihre Ausführungszeiten und 
ihre Deadlines sind die folgenden: 


OTs. Dı=15, Cı=3 


11 Wir haben hier eine etwas gröbere Unterteilung vorgenommen als Singh et al. selbst. 
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o. i D>=13, C2=5 
* 713: D3=14, C3=4 
* Ti. D4=16, C4=2 
° Ts D3=20, C3=4 
e Te: D4=22, C4=3 


Abb. 6.39 zeigt Reihenfolgebedingungen für diese Tasks. Die Tasks rı und r> sind 
sofort ausführungsbereit. 


Abb. 6.39 Reihenfolgebedingungen Ti a 


2 Us) 


Erzeugen Sie eine graphische Darstellung eines Schedules fiir diese Task-Menge 
unter Benutzung des Latest Deadline First-Verfahrens. 


6.3: Gegeben sei ein Task-System mit zwei Tasks. Task 1 hat eine Periode von 
5 und eine Ausfiihrungszeit von 2. Die zweite Task hat eine Periode von 7 und 
eine Ausfiihrungszeit von 4. Die Deadlines seien gleich den Perioden. Nehmen 
Sie an, dass wir Rate Monotonic Scheduling nutzen. Kann eine der beiden Tasks 
ihre Deadline aufgrund einer zu hohen Auslastung verpassen? Berechnen Sie diese 
Auslastung und vergleichen Sie diese mit einer Schranke, die ein Schedule garantiert. 

Erzeugen Sie eine graphische Darstellung des resultierenden Schedules! Nehmen 
Sie an, dass Tasks immer bis zum Ende ausgeführt werden, auch wenn sie ihre 
Deadline verpassen. 


6.4: Betrachten Sie dieselbe Task-Menge wie in der vorherigen Aufgabe. Benutzen 
Sie Earliest Deadline First (EDF) für das Scheduling! Kann eine Task ihre Deadline 
verpassen? Wenn nicht, warum nicht? Erzeugen Sie eine graphische Darstellung 
des resultierenden Schedules! Nehmen Sie an, dass Tasks immer bis zu ihrem Ende 
ausgefiihrt werden! 
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Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 Internatio- 
nal Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nut- 
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Kapitel 7 mM 


Check for 


Optimierung updates | 


Eingebettete Systeme müssen hinsichtlich der in diesem Buch betrachteten Bewer- 
tungskriterien effizient sein. Dies gilt insbesondere für mobile Systeme mit begrenz- 
ter Ressourcenverfügbarkeit, u.a. für Sensornetzwerke im Internet der Dinge. Es 
sind schon viele Optimierungen entwickelt worden, um die erforderliche Effizienz 
zu erreichen. Im Rahmen dieses Buches können wir nur einen Bruchteil davon be- 
schreiben. In diesem Kapitel stellen wir eine Menge an ausgewählten Optimierungen 
vor. Dieses Kapitel ist wie folgt strukturiert: zunächst präsentieren wir Optimierungs- 
techniken, die typischerweise der Übersetzung mit üblichen Compilern vorangestellt 
werden können und die früh im Entwurfsablauf benutzt werden können (sogenannte 
High-Level-Optimierungen). Danach werden wir Techniken für die Verwaltung der 
Nebenläufigkeit von Tasks vorstellen. Abschnitt 7.3 enthält fortgeschrittene Compi- 
lertechniken. Der abschließende Abschnitt 7.3.4 beschäftigt sich mit Optimierungen 
des Stromverbrauchs und des thermischen Verhaltens. 

Wie im Entwurfsfluss zu sehen, ergänzen diese Optimierungen die Werkzeuge, 
die Anwendungen auf die endgültigen Systeme abbilden. Dies wurde in Kapitel 6 
beschrieben und ist noch einmal in Abb. 7.1 dargestellt. Die Abbildung von Tasks 
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Abb. 7.1 Vereinfachter Entwurfsfluss 


und Jobs auf Prozessoren, wie in Kapitel 6 beschrieben, kann Optimierungen enthal- 
ten und Optimierungen können die Abbildung von Tasks und Jobs auf Prozessoren 
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enthalten. Daher können sich die Themenbereiche zwischen dem Kapitel 6 und dem 
gegenwärtigen Kapitel überlappen. Der Schwerpunkt des Kapitels 6 liegt bei funda- 
mentalen Techniken der Abbildung auf Ausführungsplattformen. Dagegen liegt der 
Schwerpunkt des gegenwärtigen Kapitels eher bei (ggf. optionalen) Verbesserungen 
gegenüber den fundamentalen Techniken. 


7.1 High-Level-Optimierungen 


High-Level-Optimierungen können auf den Quellcode eingebetteter Software ange- 
wendet werden. Die Erkennung regulärer Strukturen wie beispielsweise von Zugriffs- 
mustern für Felder (engl. arrays) kann auf der Quellcodeebene einfacher sein als 
auf der Ebene der Maschinensprache. Die Quellcodeebene ist auch deshalb nützlich, 
weil die Wirkung vieler Optimierungen durch eine Transformation auf dem Quell- 
code ausgedrückt und so leicht nachvollziehbar gemacht werden kann. In manchen 
Fällen kann man den Effekt einer Transformation durch Hinweise an den Compiler 
ausdrücken, was ebenfalls zur Nachvollziehbarkeit beiträgt. 


7.1.1 Einfache Schleifentransformationen 


Auf Spezifikationen lassen sich eine Reihe von Schleifentransformationen anwenden. 
Nachfolgend beschreiben wir einige davon: 


e Schleifenpermutation: Wir betrachten ein zweidimensionales Array. Der C- 
Standard [290] legt fest, dass zweidimensionale Felder im Speicher wie in Abb. 
7.2 beschrieben abgelegt werden. Aufeinanderfolgende Werte des zweiten In- 
dexes werden auf einen zusammenhängenden Speicherbereich abgebildet. Diese 
Anordnung wird auch row-major order [406] genannt. 


Abb. 7.2 Speicher-Layout für ein ae 
2-dimensionales Array p[j][k] in C A| k=@ 
j=0 k=1 
y|- 
A| k=0 
j=1 k=1 
X kz 
j=2 k=1 
v 
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Fiir ein derartiges Layout ist es tiblicherweise vorteilhaft, Schleifen so zu orga- 
nisieren, dass der letzte Index der innersten Schleife entspricht. So werden die 
Zugriffe auf den Speicher möglichst lokal gehalten. Dagegen ist die Anordnung 
von Feldern in FORTRAN unterschiedlich: hier werden benachbarte Werte des 
ersten Indexes in einen zusammenhängenden Speicherblock abgebildet (im Eng- 
lischen column-major order genannt). Veröffentlichungen, die Optimierungen 
für FORTRAN beschreiben, können daher leicht verwirren. 


Beispiel 7.1: Entsprechend dem jeweiligen Speicherlayout ist die nachfolgende 
Schleifenpermutation geeignet, die Lokalität der Zugriffe auf den Speicher zu 
erhöhen: 


for (k=0; k<m; k++) for (j=0; j<n; j++) 
for (j=0; j<n; j++) eS for (k=0; k<m; k++) 
SEIE a pLjlEk]= ... 


Diese Art von Permutationen kann eine positive Auswirkung auf die Wieder- 
verwendung von im Cache befindlichen Feldelementen haben, da die folgende 
Schleifeniteration auf eine benachbarte Speicherstelle zugreifen wird. V 


Caches sind üblicherweise so organisiert, dass auf benachbarte Speicherstellen 
wesentlich schneller zugegriffen werden kann als auf weiter von der vorherigen 
Stelle entfernte Stellen. Auf diese Weise nutzen Caches eine räumliche Lokalität 
der Speicherzugriffe. 


Definition 7.1: Wir betrachten Speicherzugriffe auf Adressen a und b. Ange- 
nommen, es liegt ein Zugriff auf a vor. Räumliche Lokalität besteht, wenn 
unter dieser Voraussetzung die Wahrscheinlichkeit eines Zugriffs auf b mit einem 
kleinen Abstand der Adressen a und b wächst. 


e Schleifen abrollen: Das Abrollen von Schleifen ist eine Standardtransformation, 
die mehrere Instanzen des Schleifenkörpers erzeugt. 


Beispiel 7.2: Dieses Beispiel zeigt eine einmal abgerollte Schleife: 


for (j=0; j<n; j++) for (j=0; j<n; j+=2) 
DEIR sco 8 > LDS a 
ELIE soo} 


V 


Die Anzahl der Kopien der Schleife wird Abrollfaktor genannt. Dabei sind Ab- 
rollfaktoren größer als zwei möglich. Das Abrollen verringert die Kosten der 
Schleife (es sind weniger Sprünge pro Ausführung des ursprünglichen Schleifen- 
körpers erforderlich) und verbessert dadurch normalerweise die Performanz. Im 
Extremfall können Schleifen vollständig abgerollt werden, was den Kontrollauf- 
wand und Sprünge vollständig beseitigt. Abrollen ermöglicht üblicherweise eine 
Reihe von Folgetransformationen und kann daher auch in den Fällen vorteilhaft 
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sein, in denen das Abrollen an sich keine direkten Vorteile bietet. Allerdings 
erhöht sich die Codegröße durch das Abrollen. Abrollen ist normalerweise auf 
Schleifen mit einer festen Anzahl an Iterationen beschränkt. 

e Schleifenfusion, Schleifenaufspaltung: Es kann Fälle geben, in denen zwei 
getrennte Schleifen zusammengeführt werden können sowie Fälle, in denen eine 
einzelne Schleife in zwei separate aufgeteilt wird. 


Beispiel 7.3: Dieses Beispiel zeigt zwei Versionen eines Softwarecodes: 


for (j=0; j<n; j++) for (j=0; j<n; j++) 
(EWI coo ; Ele ooo 8 

for (j=0; j<n; j++) 2 OLJK oss) 
pljl=pljl+ ... 


Die links dargestellte Version kann Vorteile bringen, wenn der Zielprozessor 
einen Schleifenbefehl zur Realisierung von Schleifen ohne Overhead (engl. zero- 
overhead loop instruction) besitzt, der aber nur fiir kleine Schleifen genutzt wer- 
den kann. Die rechte Version kann zu einem verbesserten Cacheverhalten führen 
(durch die verbesserte Lokalität der Referenzen auf das Array p) und vergrößert 
zudem das Potential für parallele Berechnungen innerhalb des Schleifenkörpers. 
Wie bei vielen anderen Transformationen auch, ist es schwierig zu erkennen, 
welche der Transformationen den besten Code ergibt. Vv 


7.1.2 Kachel-/Blockweise Verarbeitung von Schleifen 


Da kleine Speicher schneller als große Speicher sind (siehe Seite 186), kann die 
Verwendung von Speicherhierarchien vorteilhaft sein. Mögliche „kleine” Speicher 
sind Caches und Scratchpad-Speicher (SPMs). Informationen in diesen Speichern 
sollten einen hohen Wiederverwendungsgrad aufweisen, da die Speicherhierarchie 
sonst nicht effizient ausgenutzt werden kann. 


Beispiel 7.4: Wiederverwendungseffekte lassen sich an einer Analyse des folgenden 
Beispiels zeigen. Wir betrachten eine Matrixmultiplikation für Felder der Größe N 
x N [321]: 


for (i=0; i<N; i++) 
for(j=0; j<N; j++) { 
r=0; 
for (k=0; j<N; k++) 
r+=X[i][k]*Y[k][j]; 
zL[i]L[j]=r; 
} 


Wir betrachten die Zugriffsmuster für diesen Code. Die skalare Variable r reprä- 
sentiert Z[i, j] in allen Iterationen der innersten Schleife. Wir nehmen an, dass die 
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explizite Benutzung dieser Variablen dem Compiler hilft, hier ein Register zuzu- 
weisen. Wir nehmen an, dass die Elemente des Feldes in row-major order angeord- 
net sind (wie es in C Standard ist). Damit werden Feldelemente mit benachbarten 
(rechten) Reihenindizes in benachbarten Speicherstellen abgelegt. Also werden die 
benachbarten Stellen von X während der Iterationen der innersten Schleife geladen. 
Diese Eigenschaft ist von Vorteil, wenn das Speichersystem Prefetching verwendet 
(jedes Mal, wenn ein Wort in den Cache geladen wird, wird auch das Laden des 
darauf folgenden Wortes gestartet). Abb. 7.3 zeigt Zugriffsmuster für diesen Code. 
Die Zugriffe auf Y besitzen jedoch keine räumliche Lokalität. Wenn der Cache nicht 


E i: 
[] 5 
a 


J 
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Abb. 7.3 Zugriffsmuster fiir nicht blockweise Matrixmultiplikation 


so groß ist, dass er eine ganze Arrayspalte halten kann, wird jeder Zugriff auf Y ein 
Cachefehler sein. Daher wird es N? Zugriffe auf Elemente von Y im Hauptspeicher 
geben. 

Arbeiten im Bereich des wissenschaftlichen Rechnens führten zum Entwurf von 
geblockten oder gekachelten Algorithmen [321, 606], welche die Lokalität von 
Referenzen verbessern. Eine gekachelte Version des obigen Algorithmus mit einer 
Blockgröße von B sieht wie folgt aus!: 


for (ii=0; kk<N; ii+=B) 
for (jj=®; jj<N; jj+=B) 
for (kk=0; kk<N; kk+=B) 
for (i=ii; i<min(ii+B-1,N); iit++) 
for (j=jj; j<min(jj+B-1,N); jj++) { 
r=0; 
for (k=kk; k<min(kk+B-1,N); k++) 
r+= X[i][k]*Y[k][j]; 
ZzLil[Lj]=r; 
} 


Die innerste Schleife ist nun so begrenzt, dass ein Block der Größe B* des Arrays 
Y benutzt wird. Angenommen, ein Block der Größe B? passt in den Cache. Dann 
wird die erste Ausführung der innersten Schleife diesen Block in den Cache laden. 
Während der Ausführung der zweiten Iteration der Schleife wird dieser Block erneut 
benutzt. Insgesamt wird es B-1 Wiederverwendungen der Elemente von Y geben. 
Daher wird die Anzahl der Speicherzugriffe auf N?/ (B-1) reduziert werden. V 


! Dieser Code basiert auf der Quelle http://www.netlib.org/utk/papers/autoblock/node2.html. 
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Die Optimierung des Wiederverwendungsfaktors war das Thema umfassender 
Arbeiten. Die ursprünglichen Ansätze konzentrierten sich dabei auf die durch Ka- 
chelung erzielbaren Leistungsverbesserungen. Für Matrixmultiplikation wurde eine 
Leistungsverbesserung um einen Faktor von 3 bis 4,3 von Lam [321] berichtet. 
Weitere Verbesserungen ergeben sich bei größerem Abstand zwischen Prozessor- 
und Speichergeschwindigkeiten. Kachelung kann zudem eingesetzt werden, um den 
Energieverbrauch von Speichersystemen zu senken [103]. 


7.1.3 Aufteilen von Schleifen 


Im Folgenden betrachten wir die Schleifenaufteilung (engl. loop splitting) als eine 
weitere Optimierung, die vor dem Compilieren eines Programms angewendet werden 
kann. Diese Optimierung könnte möglicherweise auch Bestandteil eines Compilers 
sein. 

Viele Bildverarbeitungsalgorithmen verwenden Filter. Diese Filterung besteht 
vielfach aus der Betrachtung von Informationen über ein bestimmtes Pixel und eini- 
ge von dessen Nachparpixeln. Die zugehörigen Berechnungen sind normalerweise 
recht regulär. Wenn das zu betrachtende Pixel sich aber nahe des Randes eines 
Bildes befindet, existieren nicht alle benötigten Nachbarpixel und die Berechnun- 
gen müssen entsprechend angepasst werden. In einer einfachen Beschreibung des 
Filteralgorithmus können diese Modifikationen zur Folge haben, dass Tests in der 
innersten Schleife des Algorithmus durchgeführt werden müssen. Eine effizientere 
Version des Algorithmus kann erzeugt werden, indem die Schleifen so aufgespal- 
ten werden, dass ein Schleifenkörper die regulären Fälle behandelt und ein zweiter 
Schleifenkörper für die Ausnahmen zuständig ist. Abb. 7.4 ist eine graphische Dar- 
stellung dieser Transformation. 


Keine Über- Rand- 
— |prüfung, fast überprüfung, 
alle Pixel wenige Pixel 


Abb. 7.4 Aufteilung des Bildverarbeitungsbeispiels in reguläre und spezielle Fälle 


Die manuelle Aufteilung von Schleifen ist sehr kompliziert und fehleranfällig. 
Falk et al. haben einen Algorithmus veröffentlicht [159], um diesen Vorgang auch für 
größere Dimensionen zu automatisieren. Er basiert auf einer ausführlichen Analyse 
von Zugriffen auf Arrayelementen innerhalb von Schleifen. Optimierte Lösungen 
werden mit einer Polyederanalyse-Bibliothek [586] und genetischen Algorithmen 
[341] erzeugt. 
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Beispiel 7.5: Der folgende Code zeigt eine Schleifenverschachtelung aus dem 
MPEG-4-Standard, die eine Bewegungsanalyse (engl. motion estimation) durch- 
führt: 


for (z=0; z<20; z++) 
for (x=0; x<36; x++) {x1=4*x; 
for (y=0; y<49; y++) {yl=4xy; 
for (k=0; k<9; k++) {x2=x1+k-4; 
for (1=0; 1<9; l++) {y2=y1+l-4; 
for (i=0; i<4; i++) {x3=x1ti; x4=x2+i; 
for (j=0; j<4; j++) {y3=yl+j; y4=y2+j; 
if (x3<@ || 35<x3 || y3<® || 48<y3) 
then_block_1; else else_block_1; 
if (x4<@ || 35<x4 || y4<@ || 48<y4) 
then_block_2; else else_block_2; 


Unter Verwendung von Falk’s Algorithmus wird diese Verschachtelung in die 
folgende transformiert: 


for (z=0; z<20; z++) 
for (x=0; x<36; x++) {x1=4*x; 
for (y=0; y<49; y++) 
if (x>=10 || y>=14) 
for (; y<49; y++) 
for (k=0; k<9; k++) 
for (1=0; 1<9; l++ ) 
for (i=0; i<4; i++) 
for (j=0; j<4; j++) { 
then_block_1; then_block_2} 
else {y1=4xy; 
for (k=0; k<9; k++) {x2=x1+k-4; 
for (1=0; 1<9; l++) {y2=y1+l-4; 
for (i=0; i<4; i++) {x3=x1+i; x4=x2+i; 
for (j=0; j<4; j++) {y3=y1+j; y4=y2+j; 
if ( @ || 35 <x3 || ð || 48 < y3) /*& X3<@, y3<0 never true */ 
then_block_1; else else_block_1; 
if (x4 < Q|| 35 < x4 || y4 < @ || 48 < y4) 
then_block_2; else else_block_2; 


Anstatt die aufwendigen Tests in der innersten Schleife durchzufiihren, besitzt 
der Code nun eine if-Anweisung nach der dritten for-Schleifenanweisung. Alle 
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regulären Fälle werden im then-Teil dieser Anweisung behandelt. Der else-Teil 
behandelt die relativ kleine Anzahl von übrigen Fällen. V 


Eine Schleifenaufspaltung kann A Ausführungszeit [%4] 

Laufzeiten für verschiedene Ap- 400! Cavity 
plikationen und Architekturen 80] detection 
reduzieren. Relative Laufzei- co 

ten werden in Abb. 7.5 ge- Motion | 
zeigt. Fiir die Bewegungsana- na 
lyse (engl. motion estimation) 


i ich die i QSDPCM 
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sparungen möglich, die viel- & X 


fach größer sind als für die 

vorher vorgestellten einfachen Abb. 7.5 Ergebnisse für die Schleifenaufspaltung 
Transformationen. Die Schleifenaufspaltung kann beispielsweise vor der Überset- 
zung von Quellcode durch einen Compiler durchgeführt werden. 


7.1.4 Falten von Feldern 


Einige eingebettete Anwendungen, insbesondere im Multimediabereich, verwenden 
große Felder (engl. arrays). Da der Speicherplatz in eingebetteten Systemen begrenzt 
ist, sollten Möglichkeiten genutzt werden, die Speicheranforderungen von Feldern zu 
vermindern. Abb. 7.6 stellt die Adressen, die von fünf Feldern verwendet werden, als 
Funktion über der Zeit dar. Zu jedem einzelnen Zeitpunkt wird nur eine Teilmenge 
der Feldelemente benötigt. Die maximale Anzahl benötigter Elemente wird das 
Adressreferenzfenster genannt [123]. In Abb. 7.6 wird dieses Maximum durch 
einen Pfeil mit zwei Spitzen dargestellt. 


Adressen , &A 1 &B | &C 
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Abb. 7.6 Referenzmuster fiir Felder 
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Eine klassische Speicherzuteilung fiir Felder ist auf der linken Seite von Abb. 7.7 
dargestellt. Jedem Feld wird das Maximum an Platz zugewiesen, den es während der 
gesamten Ausführungszeit benötigt (wenn globale Felder betrachtet werden). 
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Abb. 7.7 Ungefaltete (links), inter-array gefaltete (Mitte) und intra-array gefaltete (rechts) Felder 


Eine mégliche Verbesserung, inter-array folding wird in der Mitte von Abb. 7.7 
dargestellt. Felder, die nicht in überlappenden Zeitintervallen gleichzeitig benötigt 
werden, können sich denselben Speicherplatz teilen. Eine weitere Verbesserung, 
intra-array folding [122], ist auf der rechten Seite von Abb. 7.7 zu sehen. Diese 
nutzt die Eigenschaft aus, dass innerhalb eines Feldes nur eine begrenzte Anzahl 
von Komponenten benötigt wird. Hier kann Speicher auf Kosten von aufwändigeren 
Adressberechnungen eingespart werden. Diese beiden Arten von Faltungen können 
zudem auch kombiniert werden. 

Andere Arten von Transformationen auf hoher Ebene wurden von Chung, Benini 
und De Micheli untersucht [103, 524]. Viele weitere verwandte Optimierungen 
wurden im Bereich des Compilerentwurfs vorgeschlagen. 


7.1.5 Wandlung von Gleitkomma- in Festkommadarstellung 


Eine oft angewendete Methode der Optimierung ist die Umwandlung von Gleitkomma- 
in Festkommaberechnungen. Diese Umwandlung wird dadurch motiviert, dass viele 
Standards für die Signalverarbeitung (wie z.B. MPEG-2 oder MPEG-4) in Form 
von C-Programmen spezifiziert sind, die Gleitkomma-Datentypen verwenden. Es ist 
dem Entwickler überlassen, eine effiziente Implementierung für diese Standards zu 
finden. 

In vielen Signalverarbeitungsanwendungen ist es möglich, Gleitkommazahlen 
durch Festkommazahlen zu ersetzen (siehe Seite 169). Dies kann beträchtliche Vor- 
teile mit sich bringen. So wurde beispielsweise für einen MPEG-2 Videokompres- 
sionsalgorithmus eine Verringerung der benötigten Prozessorzyklen um 75% und 
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des Energieverbrauchs um 76% berichtet [226]. Allerdings bringt die Umwandlung 
üblicherweise einen gewissen Präzisionsverlust mit sich. Genaugenommen gibt es 
einen Zielkonflikt zwischen verschiedenen Metriken zur Bewertung eines Entwurfs 
(siehe Abschnitt 5.3 auf Seite 278), hier z.B. zwischen den Implementierungskosten 
und der Qualität des Algorithmus (ausgedrückt z.B. in Form des Signal-Rausch- 
Abstandes (SNR), siehe Seite 156). Bei kleinen Wortlängen kann die Qualität si- 
gnifikant beeinträchtigt werden. Als Folge können Gleitkomma-Datentypen durch 
Festkomma-Datentypen ersetzt werden, dabei muss allerdings eine Analyse des 
Qualitätsverlustes erfolgen. Ursprünglich wurde diese Ersetzung manuell durch- 
geführt. Dies ist jedoch ein aufwändiger und fehleranfälliger Vorgang. Daher hat 
man versucht, diese Ersetzung mit Hilfe geeigneter Werkzeuge durchzuführen. Ei- 
nes dieser Werkzeuge ist FRIDGE (Fixed-point pRogrammIng DesiGn Environment) 
[588, 284]. Die Funktionalität von FRIDGE ist kommerziell als Teil der System 
Studio-Umgebung der Firma Synopsys verfügbar [518]. SystemC kann dazu ver- 
wendet werden, Festkomma-Datentypen zu simulieren und so den Qualitätsverlust 
zu prüfen. 

Analysen der Zielkonflikte zwischen hinzugefügtem Rauschen und der benötig- 
ten Wortlänge wurden von Shi und Brodersen [486] und auch von Menard et al. 
[391] vorgeschlagen. Das Thema ist insgesamt weiterhin Gegenstand der Forschung 
(siehe z.B. Lee et al. [336]). Auch im Bereich des Maschinellen Lernens werden 
entsprechende Verfahren untersucht [454]. 


7.2 Nebenläufigkeit von Tasks 


Wie bereits auf Seite 41 beschrieben ist die Granularität eines Task-Graphen eine 
der wichtigsten Eigenschaften von Tasks. Auch für hierarchische Task-Graphen kann 
es nützlich sein, die Granularität der Knoten zu verändern. Die Partitionierung von 
Spezifikationen in einzelne Tasks zielt dabei nicht notwendigerweise auf die Errei- 
chung maximaler Effizienz der Implementierung ab. In der Spezifikationsphase sind 
vielmehr eine klare Trennung von Belangen und ein sauberes Softwaremodell wich- 
tiger als Details der Implementierung. Eine klare Trennung der Belange beinhaltet 
beispielsweise eine klare Trennung der Implementierung abstrakter Datentypen von 
ihrer Verwendung. Im Laufe des Entwurfs werden Tasks typischerweise zu Objekten 
des Betriebssystems, also zu Prozessen (siehe Definition 4.1) bzw. Threads. Unsere 
Spezifikation könnte die fließbandartige Verwendung mehrerer Tasks vorsehen, wo- 
bei die Verschmelzung einiger dieser Tasks den Aufwand zur Kontextumschaltung 
zwischen Prozessen verringern könnte. Daher wird nicht notwendigerweise eine 
Eins-zu-eins-Beziehung zwischen den in der Spezifikation beschriebenen Tasks und 
den nachher tatsächlich implementierten Prozessen bestehen. Das bedeutet, dass ei- 
ne Neustrukturierung von Tasks angebracht sein kann. Verschmelzen und Aufteilen 
einzelner Tasks vor der Abbildung auf Prozesse erlaubt es tatsächlich, eine solche 
Neustrukturierung zu realisieren. 
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Task-Graphen können verschmolzen werden, wenn eine Task 7; unmittelbare 
Vorgängerin einer Task 7; ist und t; keine andere direkte Vorgängerin besitzt (siehe 
Abb. 7.8 mit t = 73 und t; = 74). Diese Umwandlung kann einen geringeren 


Abb. 7.8 Verschmelzen (2) (%) 
von Tasks 
G) i) > K5) 


Aufwand für die Kontextumschaltung zwischen Prozessen zur Folge haben, wenn 
der Knoten in Software implementiert ist. Allgemein kann hierdurch ein größeres 
Optimierungspotential entstehen. 

Weiterhin kann das Aufteilen von Tasks vorteilhaft sein. Beispielsweise können 
Tasks Ressourcen belegen (wie z.B. große Mengen an Speicher), während sie auf 
Eingaben warten. Um die Verwendung dieser Ressourcen zu maximieren, kann es 
sinnvoll sein, die Verwendung der Ressourcen nur in den Zeitintervallen zu erlauben, 
in denen sie tatsächlich benötigt werden. 


Beispiel 7.6: Abb. 7.9 geht davon aus, dass die Task t2 eine Eingabe während ihrer 
Ausführung benötigt. In der ursprünglichen Variante kann die Ausführung von Task 


Abb. 7.9 Aufteilen (e) (e) 
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72 nur dann beginnen, wenn diese Eingabe verfügbar ist. Wir können diesen Knoten 
nun in 7, und r,* aufteilen, so dass die Eingabe nur für die Ausführung von 75” 
erforderlich ist. Damit kann nun T} früher starten, wodurch das System einen grö- 
Beren Freiraum für Scheduling-Entscheidungen erhält. Diese größere Freiheit beim 
Scheduling kann die Auslastung von Ressourcen verbessern und es sogar ermögli- 
chen, eine bestimmte Deadline einzuhalten. Zudem kann sie einen Einfluss auf den 
benötigten Speicherplatz haben, da r, einen Teil seines Speichers freigeben könnte, 
bevor die Task sich beendet. Dieser Speicher könnte dann wiederum von anderen 


Tasks verwendet werden, während T) * auf Eingaben wartet. V 


Man könnte nun argumentieren, dass Tasks solche Ressourcen — wie große Men- 
gen Speicher — sowieso freigeben sollten, bevor sie auf Eingaben warten. Wenn man 
solche Details der Implementierung aber bereits in einer frühen Spezifikationspha- 
se berücksichtigen würde, könnte die Lesbarkeit der ursprünglichen Spezifikation 
darunter leiden. 
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Mit Hilfe einer Petrinetz-basierten Technik, die von Cortadella et al. beschrie- 
ben wurde [111], können sehr aufwendige Transformationen der Spezifikationen 
vorgenommen werden. Diese Vorgehensweise beginnt mit einer Spezifikation einer 
Menge an Tasks, die in der Sprache FlowC beschrieben werden. FlowC erweitert C 
um Prozessdefinitionen und Kommunikation zwischen Tasks, die durch READ- und 
WRITE-Funktionsaufrufe spezifiziert wird. 


Beispiel 7.7: Abb. 7.10 zeigt eine Eingabespezifikation in FlowC mit den Eingabe- 
ports IN und COEF sowie dem Ausgabeport OUT. Punkt-zu-Punkt-Kommunikation 
zwischen den einzelnen Prozessen wird durch einen unidirektionalen gepufferten 
Kanal DATA realisiert. Die Task GetData liest Umgebungsdaten ein und sendet diese 


"0 


PROCESS GetData 
CInPort IN, OutPort DATA){ 
float sample, sum; int i; 
white(1) { 
sum=ĝ; 
for (i=0; i<N; i++){ 
READ(IN, sample, 1}; sum+=sample; 
WRITE(DATA, sample, 1); 
} 
WRITE(DATA, sum/N, 1) 3 


OUT DATA COEF O 


PROCESS Filter(InPort DATA, 
InPort COEF, OutPort OUT}{ 
filoat: c,d; int: 
e=]; J=; 
white(1) { 
SELECT (DATA, COEF) { 
case DATA:READ(DATA,d,1); 
if GJ==N) (j=@; d=dxc ;WRITE(OUT,d, 1); 
} 


else j++; break; 
case COEF:READ(COEF,c,1); break; 
} 
} 
} 


Abb. 7.10 Systemspezifikation 


an den Kanal DATA. Wenn N Datenwerte gesendet wurden, wird auch ihr Durch- 
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schnittswert auf demselben Kanal übertragen. Die Task Filter liest N Werte aus 
dem Kanal (und ignoriert diese) und liest dann den Durchschnittswert, multipliziert 
diesen Wert mit c (c kann vom Port COEF gelesen werden) und schreibt das Ergebnis 
auf den Port OUT. Der dritte Parameter der READ- und WRITE-Funktionsaufrufe ist die 
Anzahl der zu lesenden oder zu schreibenden Werte. READ-Aufrufe sind blockierend, 
WRITE-Aufrufe blockieren, wenn die Anzahl an Elementen im Kanal eine bestimmte 
Obergrenze überschreitet. Die SELECT-Anweisung hat dieselbe Semantik wie die 
gleichnamige Anweisung in Ada (siehe Seite 124): die Ausführung der Task wird 
angehalten, bis eine Eingabe von einem der beiden Ports vorliegt. Dieses Beispiel 
erfüllt alle Kriterien für die Aufteilung von Tasks, die im Rahmen von Abb. 7.9 
aufgeführt wurden. Beide Tasks warten auf Eingaben, während sie bereits Ressour- 
cen belegen. Die Effizienz könnte durch Umstrukturieren der beiden Tasks gesteigert 
werden. Dabei reicht die einfache Aufteilung von Abb. 7.9 hier aber nicht aus. Bei der 
von Cortadella et al. vorgeschlagenen Methode werden FlowC-Programme zunächst 
in (erweiterte) Petrinetze übersetzt. Die Petrinetze für die einzelnen Tasks werden 
dann zu einem einzigen Petrinetz zusammengefügt. Neue Tasks werden schließ- 
lich mit Hilfe von Ergebnissen aus der Petrinetz-Theorie erzeugt. Abb. 7.11 zeigt 
eine mögliche neue Task-Struktur. In dieser gibt es eine Task, die alle Initialisie- 


"OQ 


Init tau_in(}{ 
sum=@; i=@; c=1; j=@; READ(IN, Sample ,1); 
} suml=sample; i!l; 
DATA=sample; d=DATA: 
if(j==N) { 
COLF Ọ N j=; d=d*c; WRITECOUT,d,1); 
else jlt; 
tau_coef()f{ L@:if (i<N) return; 
READ (COEF ,c. 1); DATA=sum/N; d=DATA; 
} if (j-=N)f 
j=; d=d*c; WRITE(OUT,d,1); 
} 
else j++; 


sum®; i=@; goto Lð; 


Abb. 7.11 Erzeugte Software-Tasks 


rungen ausfiihrt. Zudem gibt es je eine Task fiir jeden Eingabeport. Eine effiziente 
Implementierung wiirde eine Unterbrechung fiir jede neue Eingabe an einem der 
Ports erzeugen, wobei pro Port ein eindeutiger Interrupt verfiigbar sein sollte. Die 
Tasks könnten dann direkt durch die jeweiligen Interrupts gestartet werden, ohne 
dass ein Aufruf des Betriebssystems erforderlich wäre. Kommunikation kann über 
eine einzelne, gemeinsam benutzte globale Variable implementiert werden (wenn 
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ein gemeinsamer Adressraum fiir alle Tasks vorliegt). Der verbleibende Aufwand 
für das Betriebssystem wäre dadurch sehr klein, wenn ein Betriebssystem überhaupt 
notwendig wäre. 

Der in Abb. 7.11 gezeigte Code für die Task tau_in wurde durch die Petrinetz- 
basierte, taskübergreifende Optimierung der Task-Strukturen erzeugt. Dieser sollte 
durch Optimierungen innerhalb der Tasks weiter verbessert werden. Eine optimierte 
Version von tau_in sieht wie folgt aus: 


tau_in () { 

READ(IN, sample, 1); 

sum+=sample; i++; 

DATA=sample; d=DATA; /* Zusammenfassen von DATA & d möglich */ 
LO: if (i<N) return; 

DATA=sum/N; d=DATA; 

d=d*c; WRITE(OUT,d,1); 

sum=0; i=®; 

return; 


} 


Die Gründe für diese Vereinfachung sind: im originalen Code ergibt der Test, der 
durch die erste if-Anweisung durchgeführt wird, immer „falsch” (j ist in diesem Fall 
gleich i-1 und i und j werden auf ð zurückgesetzt, sobald i den Wert N annimmt). 
In der dritten if-Anweisung ergibt der Test stets „wahr”, da diese Anweisung nur 
erreicht wird, wenn i gleich N ist und i gleich j ist, sobald das Label L® erreicht 
wird. Zudem kann die Anzahl der Variablen verringert werden. 

Die optimierte Version von tau_in könnte von einem sehr geschickten Compi- 
ler erzeugt werden. Allerdings kann kaum einer der heute verfügbaren Compiler 
eine solche Optimierung vornehmen. Dennoch zeigt dieses Beispiel die Art von 
Transformationen, die zur Erzeugung „guter” Task-Strukturen notwendig sind. V 


Mehr Details zur Task-Erzeugung finden sich in Cortadella et al. [111] und in einer 
Publikation von Mejjer et al. [390]. 


7.3 Compiler für eingebettete Systeme 


7.3.1 Einleitung 


Für Prozessoren von PCs und Servern sind Optimierungen und Compiler verfügbar. 
Die Erzeugung von Compilern für häufig verwendete Prozessoren ist ein hinlänglich 
bekanntes Gebiet. In vielen Fällen werden Standard-Compiler auch für eingebettete 
Systeme verwendet, da sie üblicherweise kostengünstig oder gar kostenfrei erhältlich 
sind. 

Es gibt jedoch eine Reihe besonderer Gründe, spezielle Optimierungen und Com- 
piler für eingebettete Systeme zu entwerfen: 
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e Prozessorarchitekturen eingebetteter Systeme verfügen über besondere Eigen- 
schaften (siehe Seite 158). Diese Eigenschaften sollten ausgenutzt werden, um 
effizienten Code zu erzeugen. Übersetzungstechniken müssen dabei möglicher- 
weise auch die auf den Seiten 163 bis 165 beschriebenen Kompressionstechniken 
unterstützen. 

° Eine hohe Codeeffizienz ist wichtiger als eine hohe Übersetzungsgeschwindigkeit. 

e Compiler könnten dabei helfen, Echtzeitbedingungen einzuhalten und zu bewei- 
sen. Zunächst wäre es schön, wenn Compiler explizite Zeitmodelle enthielten. 
Diese könnten für Optimierungen genutzt werden, die das Zeitverhalten wirklich 
verbessern. Beispielsweise kann es von Vorteil sein, bestimmte Cachezeilen ein- 
zufrieren, um zu verhindern, dass häufig ausgeführter Code mehrmals aus dem 
Cache verdrängt und wieder hineingeladen wird. 

e Compiler können dabei helfen, den Energieverbrauch eingebetteter Systeme zu 
senken. Compiler, die Energieoptimierungen durchführen, sollten verfügbar sein. 

e Eingebettete Systeme verfügen über eine größere Vielfalt von Befehlssätzen. 
Daher gibt es mehr Prozessoren, für die Compiler verfügbar sein sollten. In 
einigen Fällen gibt es auch die Anforderung, die Optimierung von Befehlssätzen 
mit retargierbaren Compilern zu unterstützen. Bei solchen Compilern kann der 
Befehlssatz als Eingabe für ein Compiler-Erzeugungssystem spezifiziert werden. 
Solche Systeme können verwendet werden, um einen Befehlssatz experimentell 
zu verändern und dann die daraus folgenden Änderungen des resultierenden 
Maschinencodes zu analysieren. Dies ist ein Sonderfall der Erkundung des 
Entwurfsraumes und wird beispielsweise von Werkzeugen der Firma Tensilica 
unterstützt [82]. 


Einige frühe Ansätze für retargierbare Compiler werden im ersten Buch über dieses 
Thema beschrieben [378]. Optimierungen finden sich in Büchern von Leupers et al. 
[338, 339]. In diesem Abschnitt stellen wir Beispiele von Übersetzungstechniken für 
eingebettete Prozessoren vor. 


7.3.2 Energiegewahre Übersetzung 


Viele eingebettete Systeme sind batteriebetriebene Mobilgeräte. Wahrend die An- 
forderungen an die Rechenleistung von mobilen Systemen steigen, geht die Suche 
nach geeigneten künftigen Batterietechnologien weiter [415]. Daher stellt die Ver- 
fügbarkeit von Energie einen Flaschenhals für neue Anwendungen dar. 
Energieeinsparungen können auf verschiedenen Ebenen stattfinden, wie bei der 
Technologie des Herstellungsprozesses, der Gerätetechnologie, dem Schaltkreisent- 
wurf, dem Betriebssystem und den Anwendungsalgorithmen. Geeignete Überset- 
zungen von Algorithmen in Maschinencode können ebenfalls nützlich sein. Opti- 
mierungen auf hoher Ebene, wie auf den Seiten 380 bis 387 vorgestellt, können auch 
zur Verringerung des Energieverbrauchs beitragen. In diesem Abschnitt betrachten 
wir Compileroptimierungen, die den Energieverbrauch verringern können (oft auch 
low power-Optimierungen genannt). Energiemodelle sind wesentliche Bestandteile 
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aller Energieoptimierungen. Diese wurden in Kapitel 5 vorgestellt. Unter Verwen- 
dung solcher Modelle wurden die folgenden Compileroptimierungen eingesetzt, um 
den Energieverbrauch zu senken: 


Energiegewahres Scheduling: Die Reihenfolge von einzelnen Befehlen kann 
geändert werden, solange sich die Bedeutung des Programms dadurch nicht än- 
dert. Die Reihenfolge kann so geändert werden, dass die Anzahl an Bitwechseln 
auf dem Befehlsbus minimiert wird. Diese Optimierung kann auf der Ausgabe 
eines Compilers durchgeführt werden und erfordert daher keine Änderung am 
Compiler selbst. 

Energiegewahre Befehlsauswahl: Üblicherweise kann ein Abschnitt eines 
Quellcodes durch eine Menge an unterschiedlichen Maschinenbefehlsfolgen im- 
plementiert werden. Standard-Compiler verwenden die Anzahl an Instruktionen 
oder Prozessorzyklen als Kriterium (Kostenfunktion) zur Auswahl einer guten 
Sequenz. Dieses Kriterium kann durch die von dieser Sequenz benötigten Ener- 
gie ersetzt werden. Steinke et al. haben herausgefunden, dass energiegewahre 
Befehlsauswahl den Energieverbrauch um einige Prozent senken kann [509]. 
Ersetzen der Kostenfunktion ist auch bei anderen Standard-Compileroptimie- 
rungen möglich, wie z.B. register pipelining, loop invariant code motion usw. 
Auch hier liegen die möglichen Verbesserungen in Bereich einiger weniger Pro- 
zent. 

Ausnutzen der Speicherhierarchie: Wie bereits auf Seite 184 gezeigt, haben 
kleinere Speicher kürzere Zugriffszeiten und verbrauchen weniger Energie pro 
Zugriff. Durch Ausnutzung von Speicherhierarchien kann daher eine nennenswer- 
te Menge an Energie eingespart werden. Die durch Verwendung von Speicherhier- 
archien erzielbaren Energieeinsparungen zählten zu den lohnendsten Optimierun- 
gen, die Steinke [512, 510] analysiert hat. Es ist daher vorteilhaft, beispielsweise 
kleine Scratchpad-Speicher (SPM) zusätzlich zu großen Hintergrundspeichern 
einzusetzen. Alle Zugriffe auf den jeweiligen Speicherbereich werden dadurch 
weniger Energie benötigen und schneller sein als ein entsprechender Zugriff auf 
den größeren Speicher. Dabei sollte der Compiler die Zuordnung von Variablen 
und Befehlen in den SPM übernehmen. Dieser Ansatz erfordert aber, dass häufig 
verwendete Variablen und Codefolgen identifiziert und in diesen Adressbereich 
abgebildet werden. 


7.3.3 Speicherarchitektur-gewahre Übersetzung 


Übersetzungstechniken für Scratchpads 


Die Vorteile der Verwendung von SPMs wurden bereits deutlich dargelegt [35]. 
Daher stellt die Ausnutzung von SPMs einen herausragenden Fall der Ausnutzung 
von Speicherhierarchien dar. Compiler sind üblicherweise dazu in der Lage, Spei- 
cherobjekte auf bestimmte Adressbereiche im Speicher abzubilden. Dafür muss der 
Quellcode üblicherweise annotiert werden. 
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Beispiel 7.8: Speichersegmente für ARM-Prozessoren können wie folgt durch Ein- 
führung von Pragmas in den Quellcode festgelegt werden: 


# pragma arm section rwdata = "foo", rodata = "bar" 


Die nach diesem Pragma deklarierten Variablen würden dem Lese-/Schreibseg- 
ment "foo" und Konstanten entsprechend dem Nur-Lesesegment "bar" zugeordnet 
werden. Linkerbefehle können dann diese Segmente auf festgelegte Adressbereiche, 
unter anderem auch in den SPM, abbilden. V 


Dieser Ansatz wird von Compilern für ARM-Prozessoren verwendet [19]. Die- 
ser Ansatz ist jedoch nicht sehr komfortabel. Es wäre daher schön, wenn Com- 
piler solche Abbildungen für häufig verwendete Objekte automatisch durchführen 
könnten. Dafür wurden spezielle Optimierungsalgorithmen entwickelt. Ein Teil der 
Optimierungen wurde in einem separaten Buch vorgestellt [377]. Die verfügbaren 
SPM-Optimierungen fallen dabei in eine der beiden Kategorien: 


e Nicht-überlagernde (engl. non-overlaying) oder „statische” Speicherzuord- 
nungsstrategien: Bei diesen Strategien bleiben Speicherobjekte im SPM, solange 
die zugehörige Anwendung ausgeführt wird. 

e Überlagernde (engl. overlaying) oder „dynamische” Speicherzuordnungsstrate- 
gien: Bei diesen Strategien werden Objekte zur Laufzeit in den SPM verschoben 
und wieder aus diesem verdrängt. Dies stellt eine Art „Compiler-kontrollierten 
Seitenaustauschs” dar. Allerdings findet der Austausch von Objekten zwischen 
dem SPM und einem langsameren Speicher statt, anstelle der Auslagerung von 
Speicher auf Festplatten. 


Nicht-überlagernde Zuordnung 


Die nicht-überlagernde Zuordnung betrachtet die Zuordnung von Funktionen und 
globalen Variablen zum SPM. Dafür wird jede Funktion und jede globale Variable 
als Speicherobjekt modelliert. Seien 


e S die Größe des SPM, 

e sf; und sv; die Größen der Funktion i bzw. der Variablen i, 

e g die Energiemenge, die pro SPM-Zugriff eingespart wird (also die Differenz 
zwischen den Energien für einen Zugriff auf den langsamen Hauptspeicher und 
für einen Zugriff auf den SPM), 

e nf; und nv; die Anzahl der Zugriffe auf Funktion i bzw. Variable i, 

e xfi und xv; definiert als 


= | 1 wenn Funktion i auf den SPM abgebildet ist (1.1) 
0 sonst 

= | 1 wenn Variable i auf den SPM abgebildet ist (7.2) 
0 sonst 
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Dann ist das Ziel die Maximierung des Gewinns 


G=g Yi nf xf + Di avi xvi (7.3) 


i 


unter Berücksichtigung der Größenbeschränkung 


Shi xfi+ sv xvi S S (7.4) 
Se] 


i 


Dieses Problem ist ein Rucksack-Problem (engl. knapsack problem). Standard- 
Knapsack-Algorithmen können verwendet werden, um die dem SPM zuzuordnenden 
Objekte auszuwählen. Die Gleichungen (7.3) und (7.4) haben aber auch die Form 
eines Ganzzahligen Linearen Programmierungsproblems (ILP) (siehe Anhang A), 
damit können ILP-Solver verwendet werden. Die entsprechende Optimierung kann 
vor dem üblichen Übersetzungsvorgang durchgeführt werden (siehe Abb. 7.12). 


Abb. 7.12 Source- Quell- | ee Compiler Maschinen- 
to-source- code Transformation (z.B. gcc) code 
Transformation 


Speicherhierarchie- 
beschreibung 
(z.B. SPM-Größe) 


Die Optimierung betrifft Adressen von Funktionen und globalen Variablen. Üb- 
licherweise ermöglichen Compiler es, diese Adressen manuell im Quellcode fest- 
zulegen. Daher sind keine Änderungen am Compiler selbst notwendig. Der Vorteil 
solch einer Source-to-source-Transformation ist, dass sie mit Compilern für viele 
verschiedene Zielprozessoren verwendet werden kann. Damit ist es nicht notwendig, 
eine große Anzahl zielspezifischer Compiler abzuändern. 

Dieses Modell lässt sich in verschiedene Richtungen erweitern: 


e Zuordnung von Basisblöcken: Der gerade beschriebene Ansatz erlaubt es nur, 
ganze Funktionen oder Variablen im SPM zu allozieren. Folglich kann ein großer 
Teil des SPM ungenutzt bleiben, wenn Funktionen und Variablen groß sind. Da- 
her versuchen wir, die Granularität der Objekte, die im SPM alloziert werden 
können, zu reduzieren. Die naheliegende Wahl fällt dabei auf Basisblöcke als 
Speicherobjekte. Zudem betrachten wir auch Mengen benachbarter Basisblöcke, 
wobei „benachbart” definiert ist als zusammenhängende Teilgraphen im Kon- 
trollflussgraphen. Wir nennen Blöcke, die aus zusammenhängenden Teilgraphen 
entstehen, auch Multibasisblöcke [509]. Abb. 7.13 zeigt drei Multibasisblöcke 
M12, M23 und M123 für die Basisblöcke BB1, BB2 und BB3. 

Das ILP-Modell kann entsprechend erweitert werden. Seien: 
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Abb. 7.13 Basisblöcke und Multibasisblöcke: 
Pe: BB1 
Multibasisblöcke {BB1, BB2, BB3} 
{BB1, BB2} 


— sb; and sm; die Größe des Basisblocks i bzw. des Multibasisblocks i, 

— nb; und nm; die Anzahl der Zugriffe auf den Basisblock i bzw. den Multibasis- 
block i, 

— xb; und xm; definiert als 


ba | 1 wenn Basisblock i auf SPM abgebildet wird 1.5) 
0 sonst 
1 wenn Multibasisblock i auf SPM abgebildet wird 

“mi | 0 sonst (7.6) 


Dann ist das Ziel die Maximierung des Gewinns 


Si afi xfi + I nbi- xbi + X nm; + xm; + È nvi + xvi (7.7) 


i 


G=g 


unter Berücksichtigung der Größenbeschränkung 


X shio Xfi +) sbi- xbi+ X, smi- xmi + svi xvi <S (7.8) 
Y Basisblöcke i : xb; + x frei) + ` xm <1 (7.9) 


i’ emultibasicblock(i) 


Dabei ist fct(i) die Funktion, die den Basisblock i enthält und multiblock(i) 
die Menge an Multibasisblöcken, die den Basisblock i enthalten. Die zweite 
Einschränkung (7.9) stellt sicher, dass ein Basisblock nur einmal in den SPM 
abgebildet wird und nicht potenziell als Teil einer umgebenden Funktion und als 
Teil eines Multibasisblocks. 

Experimente mit diesem Modell wurden von Steinke et al. [512] durchgefiihrt. 
Bei bestimmten Benchmarkanwendungen wurden dabei Energieeinsparungen von 
bis zu 80% erreicht, wobei die Größe des SPM nur einen kleinen Bruchteil der 
gesamten Größe der Anwendung ausmachte. Ergebnisse für das bubble sort- 
Programm finden sich in Abb. 7.14. 
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Offenbar haben größere SPMs 


Eriergie Im] s einen reduzierten Energiever- 
cratchpad . 
6- Hauptspeicher brauch des Hauptspeichers zur 
CPU Folge (siehe violette Recht- 
57 ecke). Die von der CPU benö- 
a tigte Energie wird auch ver- 


ringert, da weniger Wartezy- 
37 klen erforderlich sind. Win- 
zige blaue Rechtecke zeigen 
den geringen Verbrauch des 
1- SPM an. Hierbei wurde die 
Versorgungsspannung als kon- 
0 64 128 256 512 1024 2048Größe Stantangenommen, obwohl ei- 
ne schnellere Ausführung es 
erlaubt hätte, Taktfrequenzen 
und Spannungen zu reduzie- 
ren, was noch größere Energieeinsparungen zur Folge gehabt hätte. 

Partitionierte Speicher [571]: Kleine Speicher sind schneller und benötigen weniger 
Energie pro Zugriff. Daher ist es sinnvoll, Speicher in mehrere kleinere Speicher zu 
unterteilen. In diesem Fall unterscheiden wir nicht zwischen den verschiedenen 
Arten von Speicherobjekten (Funktionen, Basisblöcke, Variablen usw.). Ein Index i 
stellt ein beliebiges Speicherobjekt dar. Seien 


Abb. 7.14 Energiereduktion durch Compiler-basierte 
Scratchpad-Belegung für bubble sort 


— S; die Größe des Speichers j, 

— si die Größe des Objekts i (wie zuvor), 

— e; der Energieverbrauch pro Zugriff auf den Speicher j, 
— ni die Anzahl von Zugriffen auf Objekt i (wie zuvor), 

— x;,j definiert als 


(7.10) 


= _ sil wenn Objekt i auf Speicher j abgebildet wird 
“ij =] o sonst 


Anstelle der Maximierung der Energieeinsparung minimieren wir nun den Gesamt- 
energieverbrauch. Daher ist das Ziel nun die Minimierung von 


C= eY g m (7.11) 
j i 
unter Berücksichtigung der Nebenbedingungen 
Vj: Is "Xj SS; (7.12) 


vi) my =] (7.13) 


J 
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Partitionierte Speicher sind insbesondere für wechselnde Speicheranforderungen 
vorteilhaft. Häufig verwendete Speicherstellen werden auch die Arbeitsmenge (engl. 
working set) einer Anwendung genannt. Anwendungen mit einer kleinen Arbeits- 
menge könnten einen sehr kleinen, schnellen Speicher verwenden, wogegen Anwen- 
dungen, die eine größere Arbeitsmenge benötigen, einem entsprechend größeren 
Speicher zugeordnet werden könnten. Ein wesentlicher Vorteil von partitionierten 
Speichern ist ihre Fähigkeit, sich der Größe des aktuellen Arbeitsmenge anzupassen. 
Weiterhin können ungenutzte Speicher zur Energieeinsparung abgeschaltet werden. 
Wir betrachten allerdings nur den „dynamischen” Energieverbrauch, der durch Spei- 
cherzugriffe verursacht wird. Zusätzlich kann aber auch Energie benötigt werden, 
wenn der Speicher nicht verwendet wird; dieser Verbrauch wird hier nicht betrachtet. 
Daher lassen sich Einsparungen durch das Abschalten von Speichern nicht in den 
Gleichungen (7.11) und (7.12) finden. 

Link-/Ladezeit-Speicherzuordnung [421]: Die Optimierung von Code auf eine 
feste SPM-Größe zur Übersetzungszeit hat einen Nachteil: der Code könnte ei- 
ne schlechte Leistung aufweisen, wenn er auf Varianten eines Prozessors mit un- 
terschiedlichen SPM-Größen ausgeführt wird. Es sollte vermieden werden, unter- 
schiedliche ausführbare Programme für Varianten eines Prozessors zu erzeugen. 
Daher sind wir an ausführbaren Programmen interessiert, die von der SPM-Größe 
unabhängig sind. Dies lässt sich durch Optimierung zur Link-Zeit erreichen. Der 
vorgeschlagene Ansatz berechnet das Verhältnis der Zugriffszahlen dividiert durch 
die Größe einer Variablen zur Übersetzungszeit und speichert diesen Wert zusam- 
men mit anderen Informationen über die Variable im ausführbaren Programm. Zur 
Ladezeit wird das Betriebssystem nach der Größe der SPMs gefragt. Daraufhin wird 
der Code modifiziert, so dass möglichst viele nutzbringende Variablen dem SPM 
zugeordnet werden. 


Überlagernde Belegung 


Große Anwendungen können mehrere hot spots (Codebereiche mit rechenintensi- 
ven Schleifen) haben. Nicht-überlagernde Ansätze liefern in diesem Zusammenhang 
nicht die bestmöglichen Ergebnisse. Für solche Anwendungen sollte der SPM für 
jeden der hot spots ausgenutzt werden. Dazu ist eine automatische Migration zwi- 
schen den einzelnen Ebenen der Speicherhierarchie erforderlich?. Diese Migration 
kann explizit in der Anwendung programmiert werden oder automatisch ausgeführt 
werden. Bei überlagernder Belegung nehmen wir meist an, dass alle Anwendungen 
zur Entwurfszeit bekannt sind. Die Algorithmen von Verma [554] und von Udaya- 
kumararan et al. [548] sind frühe Beispiele zur Behandlung dieser Situation. 

Der Algorithmus von Verma startet mit dem Kontrollflussgraphen (CFG) einer 
einzelnen Anwendung. Für die Kanten dieses Graphen betrachtet Verma die Option, 
den SPM für lokal genutzte Speicherobjekte freizuräumen. 


2 Ein Teil des Stoffes in diesem Unterabschnitt findet sich auch in einem Kapitel desselben Autors 
in einem Buch desselben Verlages [377]. 
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Beispiel 7.9: 


In Abb. 7.15 betrachten wir Basisblö- 
cke B1 bis B10 und eine Verzweigung Pefiniere A 
des Kontrollflusses bei B2. Wir neh- 
men an, dass das Feld A im linken Pfad = ( Bọ \-------- wi 
definiert, modifiziert und benutzt wird. - ' 

T3 wird nur im rechten Pfad benutzt. 


SPM-Größe=|A|=|T3| 


: Benutze T3 


Wir betrachten das potentielle Freiräu- 
men des SPMs, sodass T3 lokal dem : T3 
SPM zugewiesen werden kann. Dies ! Benutze T3 


erfordert Operationen zum Freiräumen fe ee ee 
und zum Laden in potentiell einzufi- MI... N 
genden Blöcken B9 und B10 (rote ge- 

punktete Linien: potentielle Einfügun- 
gen). Kosten und Nutzen dieser Opera- 
tionen werden anschließend in ein glo- 


bales ILP-Modell übernommen. Eine Abb. 7.15 Potentielles Freiräumen des Speichers 
Lösung dieses Modells stellt eine optimale Menge von Kopieroperationen dar. V 


Verglichen mit dem nicht-überlagernden Fall wurde für eine Menge an Benchmarks 
eine durchschnittliche Reduktion des Energieverbrauchs um 34% und der Ausfüh- 
rungszeit von 18% beobachtet. 

Der Algorithmus von Udayakumararan ist ähnlich, aber er bewertet Speicherob- 
jekte anhand des Quotienten aus der Anzahl der Speicherzugriffe und der Größe der 
Objekte. 

Schwierigkeiten ergeben sich bei der Zuordnung großer Felder zu SPMs. Tat- 
sächlich kann schon ein einzelnes Feld zu groß sein, um einem SPM zugeordnet 
zu werden. Eine einzelne Aufspaltung eines größeren Feldes kann mit der Strate- 
gie von Verma et al. [160] vorgenommen werden. Loop tiling ist eine allgemeinere 
Technik, die entweder manuell oder automatisch eingesetzt werden kann [343]. Au- 
ßerdem können Werte von Feldindices im Detail analysiert werden, um so häufig 
verwendete Elemente von Feldern im SPM zu halten [358]. 

Unsere Erklärungen betrafen bislang v.a. Code und globale Daten. Der Stack 
und der Heap benötigen besondere Aufmerksamkeit. In beiden Fällen können sehr 
einfache Lösungen möglich sein: In manchen Fällen wird man es vielleicht vorziehen, 
Stack oder Heap-Elemente nicht dem SPM zuzuordnen. In anderen Fällen können 
wir eine Analyse der Größe des Stacks [5] oder des Heaps ausführen [220], um zu 
prüfen, ob diese vollständig in den SPM passen und, falls dies der Fall ist, dem SPM 
zuweisen. 

Für den Heap haben Dominguez et al. [134] vorgeschlagen, die Lebendigkeit von 
Heap-Objekten zu überprüfen und so nicht benötigte Objekte von der Speicherver- 
waltung auszuschließen. Wann auch immer ein Objekt potentiell benötigt wird, wird 
Code erzeugt, der sicherstellt, dass sich dieses Objekt im SPM befindet. Die Objekte 
befinden sich immer an derselben Adresse im SPM, sodass das Problem der potentiell 
ungültigen Speicheradressen vermieden wird. Mclllroy et al. [385] schlagen eine dy- 
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namische Speicherverwaltung vor, welche die charakteristischen Eigenschaften von 
SPMs berücksichtigt. Bai et al. [32] schlagen vor, dass Programmierer alle Zugriffe 
über globale Zeiger mittels zweier Funktionen p2s und s2p kapseln. Diese beiden 
Funktionen konvertieren globale in lokale SPM-Adressen bzw. lokale Adressen in 
globale Adressen. 

Für Stack-Variablen haben Udayakumararan et al. [548] vorgeschlagen, zwei 
Stacks zu benutzen: einen für kurze Funktionen, deren Stack im Speicher verbleibt 
und einen für zeitaufwändige Funktionen, deren Stack dem SPM zugeordnet wird. 
Kannan et al. [282] haben vorgeschlagen, die obersten Stack-Frames in zyklischer 
Weise im SPM zu halten. Bei Funktionsaufrufen wird geprüft, ob genug Platz für 
den Frame der gerufenen Funktion im SPM vorhanden ist. Wenn der Platz nicht 
vorhanden ist, dann werden alte Stack-Frames in einen reservierten Bereich des 
Speichers geschrieben. Bei der Rückkehr von Funktionsaufrufen werden diese Stack- 
Frames zurückkopiert. Verschiedene Optimierungen zielen auf die Minimierung der 
notwendigen Überprüfungen. 


Mehrere Threads/Prozesse 


Die bisher vorgestellten Ansätze sind noch darauf beschränkt, einen einzelnen Pro- 
zess oder Thread? zu unterstützen. Im Falle mehrerer Prozesse oder Threads muss 
berücksichtigt werden, dass Objekte bei Kontextwechseln in den SPM kopiert und 
aus diesem verdrängt werden müssen. Verma schlug die drei folgenden Ansätze vor 
[555] (dabei gelten Aussagen für Prozesse sinngemäß auch für Threads): 


1. Imersten Ansatz darf nur ein einzelner Prozess gleichzeitig Speicher im SPM be- 
legen. Bei jedem Kontextwechsel wird die Information des verdrängten Prozesses 
im SPM gesichert und die Information für den auszuführenden Prozess wird wie- 
derhergestellt. Dieser Ansatz wird als speichernder/wiederherstellender (engl. 
saving/restoring) Ansatz bezeichnet. Dieser Ansatz funktioniert nicht gut für 
große SPMs, da der Kopiervorgang selbst eine erhebliche Menge an Zeit und 
Energie benötigen würde. 

2. Beim zweiten Ansatz wird der Speicherplatz des SPMs in Bereiche für die ein- 
zelnen Prozesse unterteilt. Die Größe der Partitionen wird durch eine speziel- 
le Optimierung bestimmt. Der SPM wird während der Initialisierung befüllt. 
Es sind keine weiteren compilergesteuerten Kopiervorgänge erforderlich. Da- 
her wird dieser Ansatz als nicht-speichernder/wiederherstellender (engl. non- 
saving/restoring) Ansatz bezeichnet. Dieser Ansatz ist nur sinnvoll für SPMs, 
die groß genug sind, um Speicherbereiche für mehrere Prozesse bereitzuhalten. 

3. Der dritte Ansatz ist ein hybrider Ansatz: Der SPM wird in einen gemeinsam von 
allen Prozessen genutzten Bereich und einen zweiten Bereich, in dem Prozesse 
exklusiven Speicherplatz erhalten können, unterteilt. Die Größe beider Bereiche 
wird durch eine Optimierung bestimmt. 


3 Siehe Definitionen 4.1 und 4.2. 
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Die Ansätze von Verma setzen voraus, dass die Prozesse (bzw. Threads) zur Uber- 
setzungszeit bekannt ist. Pyka et al. [463] beschreiben ein Verfahren, bei dem Pro- 
zesse dynamisch entstehen und beendet werden können sowie eine Laufzeit-SPM- 
Zuordnung, die durch einen im Betriebssystem integrierten SPM-Manager (SPMM) 
durchgeführt wird. Damit gelingt es, Speicherplatz für vorcompilierte Bibliotheken 
im SPM zuzuordnen. Leider benötigt Pykas Algorithmus eine zusätzliche Indi- 
rektionsebene. Trotz des Aufwands durch die indirekte Adressierung konnte der 
Energieverbrauch um 25%-35% im Vergleich zu einem 4-fach mengenassoziativen 
Cache reduziert werden. 

Diese zusätzliche indirekte Adressierung kann vermieden werden, wenn eine 
Speicherverwaltungseinheit (engl. Memory Management Unit (MMU)) verfügbar 
ist. Egger et al. [149] entwickelten eine Technik, die MMUs ausnutzt: Zur Uberset- 
zungszeit werden Codeabschnitte danach klassifiziert, ob sie von einer Zuordnung 
in den SPM profitieren oder nicht. Der vom SPM profitierende Code wird in einem 
bestimmten Bereich im virtuellen Adressraum gespeichert. Zu Anfang ist dieser Be- 
reich nicht auf physikalischen Speicher abgebildet. Damit tritt ein Seitenfehler auf, 
sobald der Code zum ersten Mal ausgeführt wird. Die Seitenfehlerbehandlung ruft 
dann den SPMM auf und dieser allokiert (und deallokiert) Speicherplatz im SPM, 
wobei jeweils die Umsetzungstabellen von virtuellen zu physikalischen Adressen bei 
Bedarf aktualisiert werden. Dieses Verfahren ist für die Behandlung von Code ent- 
worfen worden und ist in der Lage, dynamisch variable Mengen von Anwendungen 
zu unterstützen. Leider entspricht die Größe von aktuellen SPMs lediglich einigen 
wenigen Einträgen in aktuellen Seitentabellen, sodass die SPM-Zuordnung relativ 
grobgranular bleibt. 


Unterstützung verschiedener Architekturen und Zielfunktionen 


Bislang haben wir lediglich verschiedene Formen der Zuordnung von SPM- 
Speicherplatz betrachtet. Die verschiedenen Architekturen bilden eine weitere Di- 
mension in der Speicherplatzallokation. Implizit haben wir bislang Systeme mit 
einem einzelnen Rechenkern, einer einzigen Ebene der Speicherhierarchie und mit 
einem einzigen SPM betrachtet. Dabei existieren auch andere Architekturen. Bei- 
spielsweise können hybride Systeme sowohl Cache- wie auch SPM-Speicher ent- 
halten. Wir können versuchen, Cachefehlerraten zu reduzieren, indem wir im Fall 
von Cachekonflikten selektiv SPM-Speicher zuordnen [281, 612, 92]. Wir können 
auch verschiedene Speichertechnologien haben, wie Flash-Speicher oder anderen 
nicht-flüchtigen Speicher [562]. Für Flash-Speicher ist es wichtig, eine übermäßi- 
ge Abnutzung (engl. wear-out) einzelner Speicherbereiche durch ein gleichmäßiges 
Verteilen der Schreibvorgänge (engl. load balancing) zu vermeiden. 

SPMs können möglicherweise von mehreren Rechenkernen genutzt werden. Auch 
kann es mehrere Ebenen der Speicherhierarchie geben, von denen eventuell einige 
von mehreren Kernen gemeinsam genutzt werden. Liu et al. [350] haben einen 
ILP-basierten Ansatz für eine Optimierung für eine solche Architektur beschrieben. 
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Die Zielfunktion ist eine weitere Dimension in der Zuordnung von SPM-Speicher. 
Bislang haben wir die Minimierung der Laufzeit und des durchschnittlichen Energie- 
verbrauchs betrachtet. Es kann auch andere Optimierungsziele geben. Wir könnten 
auch den maximal möglichen Energieverbrauch (engl. Worst Case Energy Consump- 
tion (WCEC)) minimieren wollen. Die WCEC ist eine Zielfunktion in der Arbeit von 
Liu [350]. Für den Entwurf von zuverlässigen Systemen sind Zuverlässigkeit und 
Lebensdauer wichtige Zielfunktionen, insbesondere bei Systemen mit relevanter Al- 
terung (engl. aging) [565]. Auch kann es notwendig sein, das thermische Verhalten 
zu betrachten. 


7.3.4 Zusammenführung von Compilern und Zeitanalyse 


Fast keiner der heute verfügbaren Compiler beinhaltet ein Zeitmodell. Daher muss 
die Entwicklung von Echtzeitsoftware normalerweise einem iterativen Ansatz fol- 
gen: Software wird vom einem Compiler übersetzt, der über keinerlei Zeitinfor- 
mationen verfügt. Der resultierende Code wird dann mit einem Timing-Analysator 
wie aiT [4] analysiert. Wenn die Zeitbedingungen nicht eingehalten werden, müssen 
einige der Eingabedaten für den Compiler geändert und der Vorgang wiederholt 
werden. Wie nennen dies den „Versuch-und-Irrtum-basierten Ansatz der Echt- 
zeitsoftware”. Dieser Ansatz bringt mehrere Probleme mit sich. Zunächst ist die 
Anzahl der notwendigen Entwurfsiterationen anfänglich unbekannt. Weiterhin ver- 
wendet der eingesetzte Compiler „Optimierungen”, aber eine präzise Auswertung 
der Zielkriterien mit Ausnahme der Codegröße ist unmöglich. Daher können Compi- 
lerentwickler nur hoffen, dass ihre „Optimierungen” einen positiven Einfluss auf die 
Codequalität für die relevanten Ziele hat. Aufgrund des komplexen Zeitverhaltens 
moderner Prozessoren wird diese Hoffnung allerdings kaum belegt. Schließlich er- 
fordert die „Versuch-und-Irrtum”-basierte Entwicklung von Echtzeitsoftware, dass 
der Entwickler passende Änderungen der Eingabedaten für den Compiler findet, 
damit die Echtzeitbedingungen vielleicht irgendwann eingehalten werden. 

Diese Probleme können vermieden werden, wenn die Zeitanalyse in den Compiler 
integriert wird. Dies war das Ziel der Entwicklung des WCET-gewahren Compilers 
WCC an der TU Dortmund. Dabei wurde der existierende Zeitanalysator aiT in den 
experimentellen WCC-Compiler für die TriCore-Architektur integriert. Abb. 7.16 
zeigt die sich ergebende Gesamtstruktur des WCC. 

WCC verwendet die ICD-C Compiler-Infrastruktur [231] zum Lesen und Schrei- 
ben von C-Quellcode. Der Quellcode wird dann in eine Zwischendarstellung auf 
hoher Ebene (engl. High-Level Intermediate Representation (HL-IR)) umgewandelt. 
Die HL-IR ist eine abstrakte Darstellung des Quellcodes, auf die verschiedene Op- 
timierungen angewendet werden können. Die optimierte HL-IR wird dann an den 
Code-Selector übergeben. Der Code-Selector bildet Quellcodeoperationen auf Ma- 
schinenbefehle ab. Maschinenbefehle werden in der Low-Level Intermediate Repre- 
sentation (LLIR) dargestellt. Um die WCETzsr zu bestimmen, wird die LLIR in die 
von aiT verwendete CRL2-Darstellung konvertiert (durch den Konverter LLIR2CRL). 


404 7 Optimierung 


Optimierungen 


Quellcode ICD-C HL-IR > Code- 
Parser Selector 


Back- | BS LLIR aiT 
annotation 


WCET- 
Optimierter 
Masch.code 


LLIR2CRL 
O 

7 I 
B 


Optimierungen 


CRL2LLIR 
ZS 
oT 
cP 
nA 
N 


Abb. 7.16 WCET-gewahrer Compiler WCC 


aiT kann dann die WCET gsr für den angegebenen Maschinencode berechnen. Diese 
Information wird dann in die LLIR-Darstellung zurück konvertiert (durch den Konver- 
ter CRL2LLIR). WCC verwendet diese Information, um die WCET sr als Zielfunk- 
tion in der Optimierung berücksichtigen zu können. Dies kann für Optimierungen 
auf LLIR-Ebene sehr einfach erfolgen. Allerdings finden viele der Optimierungen 
auf der HL-IR-Ebene statt. WCETzsr-gesteuerte Optimierungen auf dieser Ebene 
erfordern den Einsatz von back annotation (Rückannotation) von der LLIR-Ebene 
zur HL-IR-Ebene. WCC beinhaltet diese back annotation. 

WCC wurde verwendet, um den Einfluss der Optimierung für eine WCETgsr- 
Reduktion auf den Compiler zu untersuchen. Die vielfältigen Ergebnisse beinhalten 
eine Studie des Einflusses des Einsatzes dieses Ziels auf Registerallokation [158]. 
Wie in Abb. 7.17 zu sehen, zeigen die Ergebnisse eine dramatische Verbesserung 
auf. 

Die WCETzsr kann allein durch den Einsatz der WCET-gewahren Registeral- 
lokation im WCC im Durchschnitt auf 68,8% der ursprünglichen WCET esr ge- 
senkt werden. Die größte Verbesserung ergibt eine WCETzsr von nur 24,1% der 
ursprünglichen WCETzsr. Die Auswirkungen der Kombination verschiedener Op- 
timierungen wurde von Lokuciejewski et al. [354] untersucht. Bei den betrachteten 
Benchmarks konnte Lokuciejewski eine Reduktion auf bis zu 57,1% der ursprüng- 
lichen WCET gsr feststellen. Lokuciejewski et al. haben auch maschinelles Lernen 
eingesetzt, um Heuristiken zur Reduktion der WCET zu optimieren [355]. 
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Abb. 7.17 Relative WCET gsr nach WCET-gewahrer Registerallokation 


7.4 Energieverwaltung und thermisches Management 


7.4.1 Dynamische Spannungsskalierung (DVS) 


Einige eingebettete Prozessoren unterstützen dynamische Energieverwaltung (siehe 
Seite 161) und dynamische Spannungsskalierung (siehe Seite 159). Diese Eigen- 
schaften können durch einen zusätzlichen Optimierungsschritt genutzt werden. Üb- 
licherweise folgt ein solcher Schritt nach der Codeerzeugung durch den Compiler. In 
diesem Schritt vorgenommene Optimierungen erfordern eine globale Sicht auf alle 
Tasks des Systems zusammen mit ihren Abhängigkeiten, ihrem Schlupf usw. 


Beispiel 7.10: Die Möglichkeiten, die dynamische Spannungsskalierung bietet, wer- 
den im folgenden Beispiel verdeutlicht [252]. Wir setzen einen Prozessor voraus, der 
mit den drei unterschiedlichen Spannungen 2,5 V, 4,0 V und 5,0 V betrieben werden 
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kann. Wenn wir einen Energieverbrauch von 40 nJ pro Zyklus bei 5,0 V zu Grunde 
legen, kann mit Hilfe von Gleichung (3.14) der Energieverbrauch bei Verwendung 
der anderen Betriebsspannungen berechnet werden (siehe Tabelle 7.1, hier ist 25 nJ 
ein gerundeter Wert). Weiterhin nehmen wir an, dass unsere Task innerhalb von 25 


Tabelle 7.1 Eigenschaften Vaa [V] 5,0 4,0 2,5 
eines Prozessors Energie pro Zyklus [nJ]| 40 | 25 10 
mit DVS-Funktionalität Tais [MHz] 50 40 25 

Zykluszeit [ns] 20 25 40 


Sekunden 10° Zyklen ausführen muss. Dies ist auf verschiedene Arten machbar, 
wie in den Abb. 7.18 bis 7.20 dargestellt. Bei Verwendung der maximalen Span- 
nung (Fall a), siehe Abb. 7.18) ist es möglich, den Prozessor während der nicht 
benötigten Rechenzeit von 5 Sekunden abzuschalten (wir gehen davon aus, dass der 
Energieverbrauch in diesem Zeitraum Null beträgt). 


Abb. 7.18 Mögliche Spannungsverteilung [v3 


109 Zyklen bei 50 MHz 
(Fall a) 52 A0 


Deadline 


5 10 15 20 25 tfs] 


Eine weitere Möglichkeit (Fall b)) ist es, den Prozessor anfänglich mit voller Ge- 
schwindigkeit laufen zu lassen und die Spannung zu dem Zeitpunkt zu reduzieren, 
ab dem die übrigen Zyklen mit der niedrigsten verfügbaren Spannung abgearbeitet 
werden können (siehe Abb. 7.19). 


Abb. 7.19 Spannungsverteilung (Fall b) 750M Zyklen bei 50 MHz + 


[V7] A 250M Zyklen bei 25 MHz 


5 10 15 20 25 zfs] 


Schließlich können wir den Prozessor mit einer Taktfrequenz betreiben, die gerade 
hoch genug ist, um alle Zyklen in der gegebenen Zeit abarbeiten zu können (siehe 
Abb. 7.20). 

Der zugehörige Energieverbrauch lässt sich berechnen zu 
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7: i v2 
Abb. 7.20 Spannungsverteilung (Fall c) k ] 109 Zyklen bei 40 MHz 


25 J 


5 10 15 20 25 r[s] 


Eq = 10° x 40 x 10° J = 40J (7.14) 
Ep = 750 x 10° x 40 x 107°? J + 250 x 10° x 10 * 107° J = 32,5J (7.15) 
E. = 10° *25* 10° J = 25) (7.16) 


Der minimale Energieverbrauch ergibt sich fiir die ideale Versorgungsspannung von 
4 Volt. Vv 


Im Folgenden verwenden wir den Begriff Prozessor mit variabler Spannung nur 
fiir solche Prozessoren, die mit einer beliebigen Spannung bis zu einem gegebenen 
Maximum betrieben werden können. Da es aufwändig ist, wirklich beliebige Span- 
nungen zu unterstützen, verwenden reale Prozessoren nur einige wenige festgelegte 
Spannungen. 

Die Erkenntnisse aus dem obigen Beispiel lassen sich wie folgt verallgemeinern. 
Beweise für diese Aussagen finden sich in der Veröffentlichung von Ishihara und 
Yasuura [252]. 


e Wenn ein Prozessor mit variabler Versorgungsspannung eine Task vor seiner 
Deadline beendet, kann der Energieverbrauch reduziert werden‘. 

e Wenn ein Prozessor eine einzige Versorgungsspannung V, verwendet und eine 
Task r genau an der gegebenen Deadline beendet, dann ist V, die Versorgungs- 
spannung, die den Energieverbrauch von t minimiert. 


Wenn ein Prozessor nur eine bestimmte Anzahl diskreter Spannungsstufen verwen- 
den kann, kann ein Spannungs-Schedule verwendet werden, das zwischen den beiden 
Spannungsstufen, die V;4..7 am nächsten liegen, umschaltet. Die Verwendung die- 
ser beiden Spannungen ergibt den minimalen Energieverbrauch. Es kann lediglich 
vorkommen, dass die Verwendung einer ganzzahligen Anzahl von Zyklen in einer 
kleinen Abweichung von diesem Minimum resultiert‘. 

Mit den oben gegebenen Aussagen lassen sich Spannungen zu Tasks zuordnen. 
Nun betrachten wir die Zuordnung von Spannungen zu einer Menge von Tasks. 
Dabei verwenden wir die folgende Notation: 


4 Dies ist eine explizite Formulierung einer impliziten Annahme in Lemma | der Veröffentlichung 
von Ishihara and Yasuura. 


5 Diese Anforderung wird in der ursprünglichen Veröffentlichung nicht berücksichtigt. 
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n : Anzahl der Tasks, 

EC; : Anzahl ausgeführter Zyklen von Task j, 

L _: Anzahl von Spannungsstufen des Zielprozessors, 

V; : die i-te Spannungsstufe, 1 <i < L, 

fi : die Taktfrequenz für Versorgungsspannung V;, 

d  : die globale Deadline, an der alle Tasks beendet sein müssen, 


SC; : die durchschnittliche Schalthäufigkeit während der Ausführung von Task j 
(SC; besteht aus der tatsächlichen Kapazität Cz und der Schalthäufigkeit a 
(siehe Gleichung (3.14) auf Seite 159)). 


Damit lässt sich das Spannungsskalierungs-Problem als ein Ganzzahliges Li- 
neares Programmierproblem (ILP)-Problem beschreiben (siehe Seite 425). Hierzu 
führen wir Variablen X; j ein, welche die Anzahl von Zyklen beschreiben, die bei 
einer bestimmten Spannung ausgeführt werden: 

Xi j : Anzahl der Taktzyklen, die Task j bei Spannung V; ausführt 


Das ILP-Modell macht die folgenden vereinfachenden Annahmen: 

« Es gibt nur einen Zielprozessor, der mit einer begrenzten Anzahl von diskreten 
Spannungen betrieben werden kann. 

e Der Zeitaufwand für Spannungs- und Frequenzumschaltungen ist vernachlässig- 
bar. 

e Die größtmögliche Zyklenanzahl für jede Task ist bekannt. 


Unter diesen Annahmen kann das ILP-Problem wie folgt beschrieben werden: Mi- 
nimiere 
n L 
BE) 9 SCaX ee (7.17) 
j=l i=l 


unter den Randbedingungen 


L 
oe = EC; (7.18) 
i=1 
und 
n L Xij 
2 <d (7.19) 


Das Ziel ist es, die Anzahl X;,; an Zyklen zu finden, die eine Task j bei Spannung 
V; ausgefiihrt wird. Wir haben weiter oben bereits festgestellt, dass keine Task jemals 
mehr als zwei Spannungen benötigen wird. Mit diesem Modell zeigen Ishihara 
und Yasuura, dass die Effizienz üblicherweise gesteigert werden kann, wenn Tasks 
aus einer größeren Anzahl von Spannungsstufen wählen können. Wenn ein großer 
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Schlupf verfiigbar ist, erleichtern viele Spannungsstufen das Finden von solchen 
Spannungsstufen, die dem Optimum nahe sind. In der Praxis liefern aber bereits vier 
Spannungsstufen haufig gute Ergebnisse. 

In vielen Fällen laufen Tasks tatsächlich schneller ab, als ihre vorhergesagte 
WCETzsr angibt. Diese Eigenschaft kann vom obigem Algorithmus nicht ausge- 
nutzt werden. Diese Einschränkung lässt sich beseitigen, indem Checkpoints einge- 
führt werden, zu denen die tatsächliche und worst case-Ausführungszeiten verglichen 
werden. Auf Basis dieser Information kann die Spannung potenziell reduziert werden 
[29]. Weiterhin wurde Spannungsskalierung in Multiraten-Taskgraphen vorgeschla- 
gen [479]. DVS kann mit anderen Optimierungen wie body biasing [370] kombiniert 
werden. Die body biasing-Technik dient zur Reduktion von Leckströmen. 


7.4.2 Dynamische Leistungsverwaltung (DPM) 


Um den Energieverbrauch zu reduzieren, können wir auch Stromsparzustände, wie 
auf Seite 161 beschrieben, ausnutzen. Die grundlegende Frage bei der Verwendung 
von DPM ist es, wann ein System in den energiesparenden Zustand wechseln soll. 
Einfache Ansätze verwenden nur einen einfachen Zeitgeber, um in einen energie- 
sparenden Zustand zu wechseln. Aufwändigere Ansätze modellieren die Ruhezeiten 
durch stochastische Prozesse und setzen diese dann dazu ein, um die Verwendung von 
Subsystemen mit größerer Genauigkeit vorherzusagen. Auf Exponentialverteilungen 
basierende Modelle haben sich dabei als unpräzise herausgestellt. Ausreichend ge- 
naue Modelle beruhen z.B. auf der renewal theory [490]. 

Es existieren einige Veröffentlichungen, die das Thema Energieverwaltung umfas- 
send behandeln (z.B. [46, 357]). Zudem gibt es weiterentwickelte Algorithmen, die 
DVS und DPM zu einem einzigen Optimierungsansatz zur Einsparung von Energie 
zusammenfassen [491]. Die Zuordnung von Spannungen und die Berechnung von 
Übergangszeitpunkten für DPM könnten die beiden letzten Schritte der Optimierung 
eingebetteter Software darstellen. 

Energieverwaltung ist eng mit dem Temperaturmanagement verknüpft. 


7.4.3 Verwaltung des thermischen Verhaltens 


Die Temperaturverwaltung basiert auf zur Laufzeit verfügbaren Temperaturinfor- 
mationen. Diese Informationen werden verwendet, um die Erzeugung zusätzlicher 
Wärme zu steuern, zusätzlich hat sie einen Einfluss auf die Kühlmechanismen. Die 
Steuerung von Lüftern kann als ein sehr einfacher Fall von Temperaturverwaltung 
angesehen werden. Weiterhin könnten Systeme sich komplett oder teilweise abschal- 
ten, wenn die Temperaturen einen maximalen Grenzwert überschreiten. Es können 
so wieder abgeschaltete Teile von Silizium-Chips entstehen, die man dark silicon 
nennt. Fortschrittlichere Systeme könnten zudem Taktfrequenzen und Spannungen 
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absenken. Bei Multiprozessor-Systemen könnten Tasks automatisch zwischen ver- 
schiedenen Prozessoren migriert werden. In diesen Fällen wird das Ziel „Temperatur” 
zur Laufzeit ausgewertet und dazu verwendet, einen Einfluss zur Laufzeit zu erzeu- 
gen. Die Vermeidung von Überhitzung ist das Ziel von Arbeiten von Merkel et al. 
[392] und Donald et al. [135]. 

Wenn Temperatursensoren benutzt werden, um das thermische Verhalten von 
Systemen zu beeinflussen, dann entstehen Regelkreise. Grundsätzlich können sol- 
che Regelkreise instabil werden und schwingen. Atienza et al. haben verschiedene 
Strategien für solche Regelkreise verglichen und sind zu dem Schluss gekommen, 
dass eine bestimmte fortschrittliche Regelstrategie die besten Ergebnisse erzielt, im 
Vergleich zu Standardverfahren mit größerer Performanz bei niedrigeren Tempera- 
turen [610]. Details einer solchen Strategie gehen über Basistechniken eingebetteter 
Systeme hinaus und werden daher hier nicht behandelt. 


7.5 Aufgaben 


Die folgenden Aufgaben sollten entweder zu Hause oder während einer Anwesen- 
heitsphase nach dem flipped classroom-Konzept [376] bearbeitet werden: 


7.1: Das Abrollen von Schleifen ist eine der nützlichen Optimierungen. Nennen Sie 
zwei mögliche Vorteile und zwei mögliche Nachteile des Abrollens! 


7.2: Nehmen Sie an, dass Ihr Rechner einen Hauptspeicher und einen SPM ent- 
hält und dass wir auf Variablen wie in Tabelle 7.2 (links) beschrieben zugreifen. 
Die Größen und die pro Zugriff benötigte Energie sind in der Tabelle 7.2 (rechts) 
aufgeführt. 


Variable|Größe [Bytes] | Anzahl Zugriffe 
a 1024 16 
B an 1020 Speicher Größe [Bytes] | Energie 
c 512 2048 ; ; 
d 256 512 je Zugriff 
á 128 256 Scratchpad 4096 (4k) 1,3 nJ 
f 1024 512 Hauptspeicher|262.144 (256 k)| 31 nJ 
g 512 64 
h 256 512 


Tabelle 7.2 SPM mapping: links: Zugriffe auf Variablen rechts: Speicher-Charakteristiken 


Welche der Variablen sollten dem SPM zugeordnet werden, wenn wir eine stati- 
sche, nicht-überlagernde Zuordnung der Variablen voraussetzen? Benutzen Sie ein 
ILP-Modell, um die Variablen auszuwählen! Ihr Ergebnis sollte das ILP-Modell wie 
auch die ausgewählten Variablen enthalten. Zur Lösung des ILP-Modells können Sie 
beispielsweise das Programm Ip_solve nutzen [17]. 
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7.3: Angenommen, Sie möchten loop tiling benutzen. Wie können Sie diese Schlei- 
fentransformation an die vorhandenen Speicher anpassen? 


7.4: Für welche Architekturen erwarten Sie den größten Nutzen, wenn Sie Gleit- 
kommarechnungen durch Festkommarechnungen ersetzen? 


7.5: Geben Sie eine Übersicht über Techniken zur Nutzung von Scratchpad- 
Speichern! 


7.6: Betrachten Sie das nachfolgende Programm: 


1 #include <stdio.h> 

2 #define DATALEN 15 

3 #define FILTERTAPS 5 

4 double x[DATALEN] = { 128.0, 130.0, 180.0, 140.0, 120.0, 
5 110.0, 107.0, 103.5, 102.0, 90.0, 
6 84.0, 70.0, 30.0, 77.3, 95.7 }; 
7 const double h[FILTERTAPS]={0.125,-0.25,0.5,-0.25,0.125}; 
8 double y[DATALEN]; // result; 

9 int main(void) { 

10 late aL ine 

11 for (i=; i<DATALEN;++i) { 

12 ylil = ð; 

13 for(n=0; n < FILTERTAPS; ++n) 

14 if (GM > = @) ylLil += h[n]&x[Li-n]; 

15 } 

16 for(i = 0; i < DATALEN; ++i) printf("%.2f ",y[i]); 

17 return ð; 

18 } 


Nehmen Sie mindestens die folgenden Optimierungen vor: 


« Entfernung des if der innersten Schleife (Zeile 14) 

e Abrollen der Schleife (Zeile 13) 

e Umwandlung von Gleitkomma- in Festkommaformat 
e Vermeidung aller Feldzugriffe 


Erstellen Sie die optimierte Version des Programms nach jeder der Transformationen 
und prüfen Sie die Ergebnisse auf Konsistenz! 


Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 Internatio- 
nal Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nut- 
zung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und For- 
mat erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, 
einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenom- 
men wurden. 

Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der 
genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes er- 
gibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht 
und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben 
aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers 
einzuholen. 


Kapitel 8 RM 
Test en, 


Leider können wir nicht davon ausgehen, dass ein entworfenes und ggf. produziertes 
System wie vorgesehen funktioniert. Es kann im laufenden Betrieb defekt gewor- 
den sein oder bereits Herstellungs- bzw. versteckte Entwurfsfehler aufweisen. Der 
Zweck des Testens ist es, zu überprüfen, ob ein eingebettetes/cyber-physikalisches 
System wie vorgesehen funktioniert. In diesem Kapitel gehen wir auf einige Grund- 
begriffe und Techniken dazu ein. Dazu geben wir eine kurze Einführung in die 
Ziele der Testmustererzeugung und deren Anwendung beim zu testenden System. 
In diesem Rahmen erklären wir die Begriffe der Fehlermodell, Fehlerüberdeckung, 
Fehlersimulation und Fehlerinjektion. Schließlich stellen wir schaltungstechnische 
Maßnahmen vor, mit denen das Testen unterstützt werden kann. Hierzu gehören 
insbesondere die Erzeugung von Pseudo-Zufallszahlen und die Signaturanalyse. 
Hilfreich kann es sein, Fragen der Testbarkeit bereits beim Entwurf zu berücksichti- 
gen. Bei fehlertoleranten Systemen ist es unverzichtbar, die Fehlertoleranz detailliert 
zu überprüfen. 


8.1 Anwendungsbereich 


Tests können während oder nach der Produktion (sogenannte Produktionstests) und 
auch beim Kunden (sogenannte Feldtests) stattfinden. Das Testen eingebetteter Sys- 
teme, die in cyber-physikalischen oder IoT-Systemen enthalten sind, benötigt beson- 
dere Sorgfalt: 


e Eingebettete Systeme, die in eine physische Umgebung integriert sind, können 
sicherheitskritisch sein. Daher kann ihre Fehlfunktion viel gefährlicher sein als 
beispielsweise die von Bürogeräten. Daher sind die Anforderungen an die Pro- 
duktqualität höher als bei nicht sicherheitskritischen Systemen. 

e Das Testen zeitkritischer Systeme muss das korrekte Zeitverhalten überprüfen. 
Das bedeutet, dass das Testen des funktionalen Verhaltens nicht ausreicht. 


© Der/die Autor(en) 2021 413 
P. Marwedel, Eingebettete Systeme, https://doi.org/10.1007/978-3-658-33437-6_8 


414 8 Test 


e Der Test eingebetteter Systeme in ihrer echten Umgebung kann gefährlich sein. 
So kann der Test von Steuerungssoftware eines Kernkraftwerks eine Quelle ernst- 
hafter, weitreichender Probleme sein. 


Vorbereitungen für Tests sollten nicht später als zum Ende der Entwurfsphase erfol- 
gen. Vorzugsweise sollte die notwendige Unterstützung für das Testen bereits früher 
berücksichtigt werden, verknüpft mit dem Entwurfsprozess und unter Verwendung 
der Testbarkeit als ein Zielkriterium bei der Bewertung von Entwürfen. Um Kapitel 5 
nicht zu überfrachten, haben wir dennoch alle mit dem Testen zusammenhängenden 
Aspekte in diesem Kapitel zusammengefasst. Wir stellen den Test hier als Schritt am 
Ende des Entwurfsprozesses dar (siehe Abb. 8.1), obwohl es ratsam wäre, ihn früher 
während eines realen Entwurfs in Betracht zu ziehen. Eine frühe Berücksichtigung 
von Tests ist allerdings nicht immer gängige Praxis, daher könnte Abb. 8.1 auch 
einem tatsächlichen Entwurfsprozess entsprechen. 


IN 

Spezifikation Entwurfsdatenbank Entwuri 
[7] 

| : [er] 
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Abb. 8.1 Entwurfsfluss mit abschließendem Test 


Bei Tests bezeichnen wir das im Entwurf befindliche System als zu testendes 
System oder Gerät im Test (engl. Device Under Test (DUT)). Das DUT wird einer 
Menge speziell ausgewählter Eingabemuster, sogenannter Testmuster, als Eingabe 
unterworfen, sein Verhalten wird dann analysiert und mit dem erwarteten Verhal- 
ten verglichen. Testmuster werden meist auf das reale, bereits gefertigte System 
angewendet. Testen beinhaltet eine Anzahl unterschiedlicher Aktionen: 


1. Testmustererzeugung, 
2. Testmusteranwendung, 
3. Überwachung der Antwort und 


4. Vergleich der Ergebnisse 


8.2 Testverfahren 415 


8.2 Testverfahren 


8.2.1 Testmustererzeugung für Modelle auf Gatterebene 


Durch die Erzeugung von Testmustern versuchen wir, eine Menge an Testmustern 
zu identifizieren, die es ermöglichen, ein korrekt funktionierendes von einem nicht 
korrekt funktionierenden System zu unterscheiden. Die Testmustererzeugung basiert 
normalerweise auf Fehlermodellen. Solche Fehlermodelle sind Modelle möglicher 
Fehler. Die Testmustererzeugung versucht, Tests für alle nach einem bestimmten 
Fehlermodell möglicherweise auftretenden Fehler zu erzeugen. 

Häufig wird das Haftfehler- (engl. stuck-at-) Modell verwendet. Dieses basiert auf 
der Annahme, dass eine interne Leitung einer elektronischen Schaltung entweder 
permanent mit 'Q' oder mit '1' verbunden ist. Beobachtungen zeigen, dass viele 
Fehler sich tatsächlich auf diese Art manifestieren. 


Beispiel 8.1: Wir betrachten die Schaltung in Abb. 8.2.1. Wir möchten nun testen, 
ob ein stuck-at-1-Fehler für das Signal f vorliegt. Dazu versuchen wir, f auf 'Q' 


> f 97 
Q 
cl i 1/0 
d 21 
e 1 


Abb. 8.2 Testmuster auf Gatterebene 


zu setzen, indem wir a = b ='0' setzen. Als Ergebnis sollte f den Wert '1' besit- 
zen, wenn der Fehler auftritt und ansonsten den Wert '@'. Um diesen Unterschied 
beobachten zu können, müssen wir diesen zum Ausgangssignal i weiterleiten. Dafür 
müssen wir e auf '1' und entweder c oder d auf '1' setzen. h und i werden den 
Wert '1' annehmen, wenn kein Fehler aufgetreten ist, ansonsten '®'. Das Testmus- 
ter umfasst alle Kombinationen von Eingabewerten für a bis e. Zur Erzeugung dieses 
Testmusters kann der D-Algorithmus verwendet werden [319]. V 


Das stuck-at-Fehlermodell ist die Basis für viele Techniken zur Testmustererzeugung. 
CMOS-Technologien benötigen jedoch umfassendere Fehlermodelle. Bei CMOS- 
Schaltungen können Fehler aus einer kombinatorischen Schaltung eine Schaltung 
mit internen Zuständen machen. Dieses Problem kann auftreten, wenn Leitungen 
unterbrochen sind (dieser Fall ist als stuck-open-Fehler bekannt). Als Folge können 
Verbindungen zu den Gates von Transistoren unterbrochen werden. Solche Tran- 
sistoren verhalten sich dann entweder leitend oder nicht leitend, abhängig von der 


1 In Übereinstimmung mit dem Standard ANSI/IEEE 91 kennzeichnen die Symbole >1 und & 
ODER- bzw. UND-Gatter. 
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vor der Unterbrechung im Gate vorhandenen Ladung. Auf diese Weise ,,erinnert” 
sich das Gate an sein Eingangssignal. Zudem können transiente Fehler und Verzö- 
gerungsfehler (Fehler, welche die Laufzeit einer Schaltung verändern) vorkommen. 
Verzögerungsfehler können die Folge von Übersprechen zwischen benachbarten Lei- 
tungen sein. Fehlermodelle, die solche Hardwarefehler betrachten, sind verfügbar 
[312]. 

Während gute Fehlermodelle für Hardwaretests existieren, ist dies bei Software- 
tests nicht der Fall. 


8.2.2 Selbsttestprogramme 


Eines der Hauptprobleme beim Test moderner integrierter Schaltungen ist deren 
begrenzte Anzahl an Kontakten. Dies erschwert immer mehr den Zugriff auf interne 
Komponenten. Zudem ist es mittlerweile sehr schwer, die Schaltungen bei voller 
Geschwindigkeit zu testen, da die Tester mindestens so schnell wie die Schaltung 
selbst sein müssen. Ein Ausweg aus diesem Dilemma bietet die Tatsache, dass viele 
eingebettete Systeme auf Prozessoren basieren: Prozessoren sind dazu in der La- 
ge, Testprogramme oder Diagnoseroutinen auszuführen. Solche Diagnoseroutinen 
kommen bei Großrechnern schon seit Jahrzehnten zum Einsatz. 


Beispiel 8.2: Abb. 8.3 zeigt einige Komponenten, die in einem Prozessor enthalten 
sein können. 


Befehlsregister Registerbank 


Abb. 8.3 Einige 
Komponenten der 
Prozessorhardware ss En stuck-at-@-Fehler? 


Um nun auf stuck-at-Fehler am Eingang der ALU zu testen, können wir ein kleines 
Testprogramm ausführen: 


Speichere Testmuster bestehend aus '1'-Bits im Registersatz; 

Führe XOR-Operation zwischen der Konstanten "0000...00" und dem Register aus, 
Teste, ob das Ergebnis ein '®'-Bit enthält, 

Wenn ja, melde Fehler; 

ansonsten starte Test auf nächsten Fehler V 


Ähnliche kleine Programme können für andere Fehler generiert werden. Un- 
glücklicherweise ist die Erzeugung von Diagnoseroutinen für Großrechner bisher 
hauptsächlich manuell erfolgt. Es wurde vorgeschlagen, Diagnoseroutinen automa- 
tisch zu generieren [64, 314, 53, 313, 309, 48]. 
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8.3 Auswertung von Testmustermengen und Systemrobustheit 


8.3.1 Fehlerüberdeckung 


Die Qualität von Testmustermengen kann mittels Fehlerüberdeckung als Metrik 
getestet werden. 
Definition 8.1: Die Fehlerüberdeckung ist der Prozentsatz an möglichen Fehlern, 


der mit einer gegebenen Menge an Testmustern gefunden werden kann: 


Anzahl erkennbarer Fehler für gegebene Testmuster-Menge 


Fehlerüberdeckung = 
PETE Anzahl von im Fehlermodell möglichen Fehlern 


In der Praxis ist eine Fehlerüberdeckung im Bereich von mehr als 98% bis 99% 
zur Erzielung einer guten Produktqualität erforderlich. Die Anforderungen können 
für bestimmte Systeme noch höher liegen. Für manche Hardware, wie z.B. Batterien, 
können zudem spezielle Fehlermodelle erforderlich sein. 

Zusätzlich zur Erzielung einer hohen Fehlerüberdeckung muss auch eine ho- 
he sogenannte correctness coverage erzielt werden. Dies bedeutet, dass fehlerfreie 
Systeme auch als solche erkannt werden müssen. Ansonsten wäre es möglich, eine 
100%-ige Fehlerüberdeckung zu erreichen, indem man alle Systeme als fehlerhaft 
klassifiziert. 

Um die Anzahl an Möglichkeiten zur Validierung von Systemen zu erhöhen, 
wurde vorgeschlagen, Testmethoden bereits in der Entwurfsphase anzuwenden. Bei- 
spielsweise können Fehlermustermengen auf Softwaremodelle von Systemen ange- 
wendet werden, um zu überprüfen, ob sich zwei Softwaremodelle identisch verhalten. 
Zeitaufwendigere formale Methoden müssen nur in den Fällen zum Einsatz kommen, 
in denen das System diese testbasierte Gleichheitsprüfung bestanden hat. 


8.3.2 Fehlersimulation 


Es ist momentan nicht möglich (und dies wird sich voraussichtlich auch nicht ändern), 
das Verhalten von Systemen in Gegenwart von Fehlern vollständig vorherzusagen 
oder die Fehlerüberdeckung analytisch zu berechnen. Daher wird das Verhalten von 
Systemen unter Fehlereinfluss üblicherweise simuliert. Diese Art von Simulation 
wird Fehlersimulation genannt. Bei der Fehlersimulation werden Systemmodel- 
le verändert, um das Verhalten des Systems bei Vorhandensein eines bestimmten 
Fehlers wiederzugeben. Die Fehlersimulation zielt darauf 


e den Effekt eines Fehlers auf Systemebene herauszufinden (d.h. zu wissen, ob ein 
Fehler redundant ist), 

e zu wissen, ob Mechanismen zur Verbesserung der Fehlertoleranz tatsächlich eine 
Verbesserung bringen. 
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Definition 8.2: Fehler werden redundant genannt, wenn sie das beobachtbare Ver- 
halten des Systems nicht beeinflussen. 


Die Fehlersimulation erfordert die Simulation des Systems fiir alle im Fehlermo- 
dell möglichen Fehler und für eine möglicherweise große Menge an unterschied- 
lichen Eingabemustern. Dementsprechend ist Fehlersimulation ein extrem zeitauf- 
wendiger Vorgang. Zur Beschleunigung wurden daher verschiedene Verfahren vor- 
geschlagen. 

Ein solches Verfahren bezieht sich auf Fehlersimulation auf Gatterebene. In die- 
sem Fall sind die internen Signale einzelne Bits. Dies ermöglicht die Abbildung 
eines Signals auf ein einzelnes Bit eines Maschinenworts eines Simulationsrech- 
ners. UND- und ODER-Maschinenbefehle können damit verwendet werden, um 
Boolesche Netzwerke zu simulieren. Damit würde aber nur ein einzelnes Bit pro 
Maschinenwort verwendet werden. Die Effizienz wird durch parallele Fehlersimula- 
tion verbessert. 


Definition 8.3: Fehlersimulation heißt parallele Fehlersimulation, wenn n > 1 
verschiedene Testmuster gleichzeitig simuliert werden, wobei n die Länge eines 
Bitvektors ist, der als Datentyp von der simulierenden Maschine unterstützt wird. 


Die Werte jedes der n Testmuster werden auf eine unterschiedliche Bitpositi- 
on im Maschinenwort abgebildet. Die Ausführung derselben Menge an UND- und 
ODER-Befehlen simuliert dann das Verhalten des Booleschen Netzwerks für n Test- 
muster anstelle von nur einem Muster. AVX-Befehle (siehe Seite 170) sind für diese 
Simulation sehr hilfreich. 


8.3.3 Fehlerinjektion 


Für reale Systeme kann Fehlersimulation zu zeitaufwendig sein. Wenn echte Systeme 
verfügbar sind, kann stattdessen Fehlerinjektion zum Einsatz kommen. Bei der Feh- 
lerinjektion werden real existierende Systeme modifiziert und der Gesamteinfluss 
auf das Systemverhalten überprüft. Fehlerinjektion beruht nicht auf Fehlermodellen 
(auch wenn sie zum Einsatz kommen können). Daher hat die Fehlerinjektion das Po- 
tential, Fehler zu erzeugen, die von einem Fehlermodell nicht vorhergesagt worden 
wären. Wir unterscheiden zwischen zwei Arten der Fehlerinjektion: 


e lokale Fehler innerhalb des Systems und 

e Fehler in der Umgebung (Verhalten, das nicht der Spezifikation entspricht: bei- 
spielsweise können wir die Reaktion des Systems testen, wenn es außerhalb der 
vorgesehenen Temperatur- oder Strahlungsbereiche betrieben wird). 


Für die Fehlerinjektion kommen verschiedene Methoden zum Einsatz: 


e Fehlerinjektion auf Hardwareebene: Beispiele sind Manipulation von Signalpe- 
geln an Kontakten, elektromagnetische und nukleare Strahlung und 
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e Fehlerinjektion auf Softwareebene: Beispiele sind hier das Kippen von Bits im 
Speicher. 


Der Testvorgang selbst kann einen Einfluss auf das Verhalten des Systems haben, 
z.B. durch eine zusätzliche Strombelastung oder ein geöffnetes Gehäuse. Dieser 
Einfluss sollte so gering wie möglich, im besten Fall vernachlässigbar, sein. 

Experimente von Kopetz [304] zeigen, dass Software-basierte Fehlerinjektion 
in der Tat genauso effektiv wie Hardware-basierte Fehlerinjektion ist. Die einzige 
nennenswerte Ausnahme stellt hier nukleare Strahlung dar. Diese erzeugte Fehler, 
die mit anderen Methoden nicht erzeugt wurden. 


8.4 Entwurf für Testbarkeit 


8.4.1 Motivation 


Ansätze für die Testmustererzeugung für Boolesche Schaltungen wurden in Unterab- 
schnitt 8.2.1 vorgestellt. Für Schaltungen, die endliche Automaten implementieren, 
ist die Testmustererzeugung schwieriger. Der Vergleich, ob zwei endliche Automaten 
äquivalent sind, kann komplexere Eingabefolgen erfordern [302]. 


Beispiel 8.3: Wir betrachten das Zustandsdiagramm in Abb. 2.25, das hier der Über- 
sichtlichkeit halber noch einmal in Abb. 8.4 dargestellt ist: Angenommen, wir möch- 


Abb. 8.4 Zu testender 
endlicher Automat 


iv 
/ hf i/y i/: 
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ten den Ubergang von Zustand C zu Zustand D testen. Dies erfordert, dass wir 
zuerst Zustand C durch eine passende Folge von Eingabemustern erreichen. Darauf- 
hin miissen wir das Eingabeereignis i erzeugen und tiberpriifen, ob die Ausgabe y 
erzeugt wird. Außerdem müssen wir überprüfen, ob wir Zustand D erreicht haben. 
Dieser Vorgang ist recht kompliziert, braucht eine Menge Zeit und ist anfällig für 
die Beeinflussung durch andere auftretende Fehler?. V 


Dieses Beispiel zeigt: wenn Testen nur im Nachhinein stattfindet, kann es sehr 
schwierig sein, ein System zu testen. Um Tests zu vereinfachen, kann spezielle Hard- 
ware hinzugefügt werden. Der Vorgang, für bessere Testbarkeit zu entwerfen, nennt 


2 Der gesamte Test dieses speziellen Automaten wird dadurch vereinfacht, dass der Automat eine 
lineare Kette an Transitionen enthält (siehe auch die Übungsaufgaben zu diesem Kapitel). 
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sich Entwurf fiir Testbarkeit (engl. Design for Testability (DfT)). Ein bedeuten- 
des Beispiel hierfiir ist die Verwendung spezieller Hardware zum Testen endlicher 


Automaten. 


8.4.2 Scanpfad-Entwurf 


Das Erreichen bestimmter Zustände und die Überwachung von Zuständen, die aus 
der Anwendung von Eingabemustern resultieren, wird mit dem Scanpfad-Entwurf 
(engl. scan design) wesentlich erleichtert. Beim Scanpfad-Entwurf werden alle Flip- 
flops, die Zustände speichern, verbunden und bilden serielle Schieberegister (siehe 
Abb. 8.5). Die Schaltung enthält drei D-Flipflops DFF und einen Multiplexer an 
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jedem Flipflop-Eingang. Unter Verwendung des Kontrolleingangs der Multiplexer 
(unter den Multiplexereingängen dargestellt) können wir die Flipflops entweder an 
das Schaltnetz anschließen, das aus aktuellem Zustand und aktuellen Eingabedaten 
den Folgezustand berechnet oder wir verbinden die Flipflops, sodass sie eine serielle 
Kette bilden. Wenn wir die Multiplexer in den Scan-Modus versetzen, können wir 
nacheinander Zustandbits in die Scan-Kette laden (ein Bit pro Taktzyklus). Auf diese 
Weise können wir seriell jeden beliebigen Zustand in die drei Flipflops laden. In ei- 
ner zweiten Phase können wir ein Eingabemuster am endlichen Automaten anlegen, 
während sich die Multiplexer im normalen Modus befinden. Nach dem nächsten 
Taktzyklus befindet sich der Automat dann in einem neuen Zustand. Dieser neue 
Zustand kann nun in der dritten und letzten Phase wieder seriell hinausgeschoben 
werden (wieder ein Bit pro Taktzyklus). Im Endergebnis müssen wir uns also beim 
Erzeugen von Tests für den endlichen Automaten keine Gedanken darüber machen, 
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wie bestimmte Zustände erreicht werden können und wie überwacht werden kann, 
ob die Boolesche Funktion ö, die den Folgezustand berechnet, korrekt implemen- 
tiert wurde. Tatsächlich hat die Tatsache, dass wir nun ein zustandsbasiertes System 
betrachten, nur einen Einfluss auf die beiden (einfachen) Schiebephasen, damit kann 
die Testmustererzeugung für (zustandslose) Boolesche Netzwerke verwendet wer- 
den, um auf korrekte Ausgaben zu prüfen. Damit reicht es also aus, Testmustererzeu- 
gungsverfahren für Boolesche Funktionen (zustandslose Netzwerke) zu verwenden 
und man muss sich keine Gedanken über komplexe Eingabesequenzen und ähnliches 
machen. 

Für einzelne Chips funktioniert Scan-Design sehr gut. Wenn mehrere Schaltun- 
gen auf einer Platine integriert werden, benötigt man eine Technik, um Scan-Ketten 
mehrerer Chips miteinander zu verbinden. JTAG ist ein Standard, der dies ermög- 
licht. Dieser Standard definiert Register als Grenzen aller Chips und eine Anzahl von 
Testpins und Steuerbefehlen, um alle Chips miteinander in Scan-Ketten zu verbinden. 
JTAG wird auch als boundary scan bezeichnet [447]. 


8.4.3 Signaturanalyse 


Um zu verhindern, dass auch die Antwort des zu testenden Systems hinausgeschoben 
wird, können Antworten komprimiert werden. Dazu kann eine Konfiguration wie in 
Abb. 8.6 verwendet werden. Erzeugte Testmuster werden als Eingabe (auch Stimuli 


Testmuster- Zu testendes Antwort- Vergleich 
> -> > 
erzeugung System (DUT) kompaktierung mit Referenz 


Abb. 8.6 Testen eines Systems 


genannt) für das DUT verwendet. Die Antwort des DUT wird dann zu einer Signatur 
komprimiert, welche die Antwort beschreibt. Diese Antwort wird dann später mit 
der erwarteten Antwort verglichen. Die erwartete Antwort selbst kann mit Hilfe von 
Simulation berechnet werden. 

Normalerweise wird die Komprimierung mit Hilfe linearer rückgekoppelter 
Schieberegister (engl. Linear Feedback Shift Register (LFSR)) durchgeführt, die 
über eine Rückkopplung mittels XOR verfügen. 


Beispiel 8.4: Abb. 8.7 zeigt ein 4-Bit LFSR (links) und das zugehörige Zustands- 
diagramm (rechts) [319]. Blaue gestrichelte Linien zeigen die Eingabe einer '1' an, 
rote durchgezogene Linien die Eingabe einer '®'. Die ausgewählte Rückkopplung 
erzeugt alle möglichen Signaturen. Während des Tests wird die Antwort des geteste- 
ten Systems an die Eingänge des LFSR angelegt. Das LFSR erzeugt daraufhin eine 
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Abb. 8.7 Linear riickgekoppeltes Schieberegister zur Kompaktierung von Antworten: links: Schalt- 
plan; rechts: Zustandsdiagramm 


Signatur, welche die Antwort beschreibt. Die Signatur ist wesentlich kompakter als 
der komplette Strom von Eingabedaten. V 


Da nicht die gesamte Antwort, sondern nur eine Signatur gespeichert wird, können 
unterschiedliche Antwortmuster auf dieselbe Signatur abgebildet werden. Wie hoch 
ist nun die Wahrscheinlichkeit dafür, eine korrekte Signatur aus einer inkorrekten 
Antwort zu erhalten? 

Im Allgemeinen erzeugt ein n-Bit-Signaturgenerator 2” Signaturen. Bei einer 
Antwort des DUT von m Bits können wir im besten Fall 2“"-”) Antworten gleich- 
mäßig auf eine Signatur abbilden. Wir erwarten nun, dass eine bestimmte Signa- 
tur für die korrekte Antwort des Systems erzeugt wird. Damit würden aber auch 
2("-") _ | inkorrekte Antworten auf dieselbe Signatur abgebildet werden. Bei m Bit 
langen Antworten gibt es insgesamt 2” — 1 inkorrekte Antworten. Daher beträgt die 
Wahrscheinlichkeit, dass eine inkorrekte Antwort auf die korrekte Signatur abgebil- 
det wird (unter der Voraussetzung, dass die gegebenen Muster gleichmäßig auf die 
Signaturen verteilt sind): 


andere, auf dieselbe Signatur abgebildete Muster 
P = Pr | ———— J (8.1) 
gesamte Anzahl anderer Muster 


20n) = i 
2(m-n) 

x 72 für m >n (8.3) 
1 

x ah firm >n (8.4) 


Damit ist die Wahrscheinlichkeit, dass eine korrekte Signatur aus einer inkorrekten 
Testantwort erzeugt wird, sehr gering, wenn das Schieberegister lang ist. Beispiels- 
weise können 32-Bit Register zum Einsatz kommen. Trotzdem ist es möglich, dass 
falsche Werte am Eingang zu einer korrekten Signatur führen. Diesen Effekt nennt 
man Aliasing. Die komprimierten Antworten verhalten sich sehr ähnlich wie CRC- 


8.5 Aufgaben 423 


Zeichen, die zur Absicherung bei der Dateniibertragung benutzt werden und die 
ebenfalls mit LFSR-Registern berechnet werden. Bei sicherheitskritischen Systemen 
ist eine sorgfaltige Analyse des Aliasings ratsam. 


8.4.4 Erzeugung von Pseudozufalls-Testmustern 


Bei Chips, die eine große Anzahl an Flipflops enthalten, kann das Hineinschieben 
der Testmuster einige Zeit dauern. Der Vorgang der Erzeugung von Mustern auf dem 
Chip kann durch die Integration von Hardware zur Testmustererzeugung auf dem 
Chip beschleunigt werden. So können zum Beispiel Pseudozufallsmuster (die auch 
von den LFSRs erzeugt werden) als Testmuster zum Einsatz kommen. 


Beispiel 8.5: Wir können die Schaltung aus Abb. 8.7 wie in Abb. 8.8 gezeigt abän- 
dern. Diese Schaltung erzeugt alle möglichen Testmuster mit Ausnahme des Musters, 
das ausschließlich aus Nullen besteht. 


4 Bit Schieberegister 
Takt —? 


OO OOO 
an 
DOCO 

V 


Abb. 8.8 Linear rückgekoppeltes Schieberegister zur Testmustererzeugung 


H 


Ein Muster aus lauter Nullen muss vermieden werden, da ansonsten der Generator 
anhält, wenn er das Muster erreicht. Die so erzeugten Muster untersuchen zu testende 
Systeme meist sehr viel besser als einfache Zähler. 


8.5 Aufgaben 
Die folgenden Aufgaben sollten entweder zu Hause oder während einer Anwesen- 
heitsphase nach dem flipped classroom-Konzept [376] bearbeitet werden: 


8.1: Betrachten Sie die Schaltung in Abb. 8.2 und erzeugen Sie ein Testmuster für 
einen stuck-at-0-Fehler beim Signal A. 


8.2: Welches Zustandsdiagramm entspricht dem LFSR aus Abb. 8.9? 


424 8 Test 


Abb. 8.9 LFSR 4 Bit Schieberegister 
Takt —4 
— >] -1 mi E: 
=a 
a 
——> 


fe ee 


8.3: Geben Sie fiir den endlichen Automaten aus Abb. 8.4 Testmuster und erwar- 
tete Antworten an. Die Testmuster miissen als eine Folge von Paaren (Testmuster, 
erwartete Antwort) angegeben werden. In Abb. 8.4 gezeigte Ereignisse können als 
Testmuster verwendet werden. Wir gehen davon aus, dass sich der Automat nach 
dem Einschalten im Ausgangszustand befindet. Erstellen Sie einen umfassenden 
Test für alle möglichen Übergänge! Denken Sie dabei daran, dass die besondere 
Kettenstruktur des Automaten das Testen vereinfacht. 


Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 Internatio- 
nal Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nut- 
zung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und For- 
mat erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, 
einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenom- 
men wurden. 

Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der 
genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes er- 
gibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht 
und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben 
aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers 
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Anhang A 
Ganzzahlige Lineare Programmierung 


In diesem Buch wird der Anhang benutzt, um grundlegende Kenntnisse zu ver- 
mitteln, die für das Verständnis der vorangegangenen Kapitel erforderlich sind, die 
man aber nicht unbedingt voraussetzen kann. Dabei werden drei Themenkreise 
behandelt. Im aktuellen Anhang wird die Ganzzahlige Lineare Programmierung 
vorgestellt. Die Ganzzahlige Lineare Programmierung (engl. Integer Linear Pro- 
gramming (ILP)) ist eine mathematische Optimierungstechnik, die auf eine große 
Zahl von Optimierungsproblemen anwendbar ist. ILP-Modelle sind ein allgemeiner 
Ansatz, um Optimierungsprobleme zu lösen. 

ILP-Modelle bestehen aus zwei Teilen: einer Kostenfunktion und einer Menge an 
Nebenbedingungen. Beide Teile referenzieren eine Menge X = {x;} ganzzahliger 
Variablen. Die Kostenfunktionen müssen lineare Funktionen dieser Variablen sein. 
Damit haben sie die allgemeine Form 


C= BY aixi, with a; € R, xi € No (A.1) 


Die Menge der Nebenbedingungen J muss ebenfalls aus linearen Funktionen tiber 
ganzzahligen Variablen bestehen. Diese miissen folgende Form haben: 


Vj eJ: ) bijxi 2 cy with bij,cj ER (A.2) 


Definition A.1: Die Ganzzahlige Lineare Programmierung (ILP) beschreibt die 
Aufgabe, die Kostenfunktion von Gleichung (A.1) unter den gegebenen Neben- 
bedingungen von Gleichung (A.2) zu minimieren. Wenn alle Variablen entweder 
den Wert 0 oder 1 annehmen müssen, dann wird das entsprechende Modell ein 
0/1-ILP-Modell genannt. In diesem Fall werden die Variablen auch als (binäre) 
Entscheidungsvariablen bezeichnet. 


Hierbei kann in Gleichung (A.2) > durch < ersetzt werden, wenn die Konstanten 
bi j entsprechend angepasst werden. Der Fall von negativen Variablen x; entsteht, 
wenn man zulässt, dass x; einen beliebigen ganzzahligen Wert annehmen kann. 
Er kann in den Fall nicht-negativer Variablen gewandelt werden, indem man die 
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Konstanten mit -1 multipliziert. Anwendungen, welche die Maximierung einer 
Gewinnfunktion C’ erfordern, können in die obige Form gebracht werden, indem 
C = -C’ gesetzt wird. 


Beispiel A.1: Unter der Annahme, dass x;, x2 und x3 ganzzahlig sein müssen, stellt 
das folgende Gleichungssystem ein 0/1-ILP-Modell dar: 


C = 5x1 + 6x2 + 4x3 (A.3) 
Xp t+m+xX322 (A.4) 
xı <1 (A.5) 
x2 <1 (A.6) 
x3 <1 (A.7) 


Durch die Nebenbedingungen nehmen alle Variablen entweder den Wert 0 oder 1 an. 
Es gibt vier mögliche Lösungen, diese sind in Tabelle A.1 aufgeführt. Die Lösung 
mit Kosten von 9 ist optimal. 


Tabelle A.1 Mögliche Lösungen des vorgestellten ILP-Problems x | x2 | 3 | C 
0 1 1 | 10 
1 | 0 1/9 
1 1 O | il 
1 1 1 |15 
V 


ILP ist eine besondere Variante der Linearen Programmierung (LP). Bei Linearer 
Programmierung können Variablen beliebige reelle Werte annehmen. ILP- und LP- 
Modelle sind optimal durch Anwendung mathematischer Programmiertechniken 
lösbar. Leider ist ILP NP-vollständig (LP hingegen nicht) und die Ausführung einer 
ILP-Optimierung kann sehr viel Zeit erfordern. 

Dennoch sind ILP-Modelle nützlich, um Optimierungsprobleme zu modellieren, 
solange die Modelle nicht sehr groß werden. Die Modellierung von Optimierungs- 
problemen als ILP-Probleme ist trotz der Komplexität des Problems sinnvoll: viele 
Probleme lassen sich in akzeptabler Zeit lösen. Wenn dies einmal nicht der Fall ist, 
liefert das ILP-Modell einen guten Ausgangspunkt zur Entwicklung von Heuristi- 
ken. Die Ausführungszeit hängt von der Anzahl der Variablen und der Anzahl und 
Beschaffenheit der Nebenbedingungen ab. Gute ILP-Löser (wie Ip_solve [17] oder 
CPLEX) können gut strukturierte Probleme mit einigen tausend Variablen in akzep- 
tabler Zeit, meist im Bereich von Minuten, lösen. Mehr Informationen zum Thema 
ILP und LP findet man in Fachliteratur zu diesen Themen, z.B. bei Wolsey [594]. 


Anhang B 
Kirchhoffsche Gesetze und Operationsverstarker 


Unsere Beschreibung von D/A-Wandlern ab Seite 197 setzt einige Grundkenntnisse 
über Operationsverstärker voraus. Informatikstudenten verfügen häufig nicht über 
dieses Wissen, daher stellen wir die notwendigen Grundlagen in diesem Anhang 
vor. Diese Grundlagen bauen auf dem Verständnis der Kirchhoffschen Regeln auf, 
die hier der Vollständigkeit halber ebenfalls vorgestellt werden. 


Kirchhoffsche Regeln 


Die Kirchhoffschen Regeln sind ein Mittel, um elektrische Schaltungen zu analysie- 
ren. Die erste Regel ist die Knotenregel. Diese gilt für Knoten wie den in Abb. B.1 
gezeigten. 


Abb. B.1 Ein Knoten in einer elektrischen Schaltung Jä 


Theorem B.1 (Kirchhoffsche Knotenregel [274]): In jedem Punkt einer elektri- 
schen Schaltung ist die Summe der zu diesem Punkt hinfließenden Ströme gleich 
der Summe der von diesem Punkt wegflieBenden Ströme. Formal gilt also fiir jeden 


Knoten einer Schaltung: 
> ix =0 (B.1) 


k 


Wenn diese Regel in der Form von Gleichung (B.1) verwendet wird, dann miissen 
Ströme, die durch einen von einem Knoten wegführenden Pfeil gekennzeichnet sind, 
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als negativ betrachtet werden, wobei diese Zählung von der tatsächlichen Richtung 
des Stromflusses unabhängig ist. 


Beispiel B.1: Für die Ströme aus Abb. B.1 gilt 


u+b-b+u=0 (B.2) 


i +i +i4 = i3 (B.3) 


Diese Invarianz ist eine Folge der Erhaltung der elektrischen Ladung. Ohne diese 
Regel wiirde die Gesamtladung nicht konstant bleiben und die Spannung ansteigen. 

Die zweite Kirchhoffsche Regel beschreibt Maschen in einer Schaltung und ist 
daher auch als Maschenregel bekannt. Ein Beispiel ist in Abb. B.4 zu sehen. 


Abb. B.2 Eine Masche in % 
einer elektrischen Schaltung <— 
1 
3 R 3 
D R 
YO a 
ON 
UD 
= 
yi 


Theorem B.2 (Kirchhoffsche Maschenregel [274]): Die Summe der Potentialun- 
terschiede tiber alle Elemente einer Masche muss Null ergeben . Fiir jede Masche in 
einer Schaltung gilt also die Formel: 


` V = 0 (B.4) 
k 


Wenn Spannungen entgegen der Pfeilrichtung betrachtet werden, müssen diese als 
negativ angesehen werden. 


Beispiel B.2: Für die Schaltung in Abb. B.2 gilt 
Vi — Vo — V3 + V4 = 0 (B.5) 


Die zugrunde liegende Ursache hierfiir ist die Energieerhaltung. Ohne diese Regel 
könnte eine Ladung in der Masche beschleunigt werden und die Ladung würde an 
Energie gewinnen, ohne dass an einer anderen Stelle Energie „verbraucht” werden 
würde. 

Im allgemeinen ist es unwichtig, in welche Richtung die Elektronen in einer Schal- 
tung tatsächlich fließen und welcher Anschluss das höhere Potential im Vergleich 
zu einem anderen Anschluss besitzt. Die Richtung der Pfeile kann also beliebig 
gewählt werden. Es muss nur sichergestellt sein, dass die Richtung der Pfeile bei 
der Anwendung der Kirchhoffschen Regeln berücksichtigt wird. Wenn Pfeile für 
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Spannungen und Ströme über Komponenten in unterschiedliche Richtungen zeigen, 
muss die Gleichung für diese Komponente dies berücksichtigen. 


Beispiel B.3: Daher liest sich beispielsweise das Ohmsche Gesetz für den Widerstand 
R3 in Abb. B.2 wie folgt: 


b=-2 (B.6) 


Natürlich wird man meist versuchen, die Richtung von Spannungen und Strömen so 
zu wählen, dass die Anzahl der erforderlichen Minuszeichen minimiert wird. 


Operationsverstärker 


In elektronischen Schaltungen muss oft ein Signal x(t) verstärkt werden, um ein ver- 
stärktes Signal y(t) = a- x(t) mit a > 1 zu erhalten. a wird der Verstärkungsfaktor 
genannt. Es wäre sehr aufwendig, unterschiedliche Schaltungen für jeden mögli- 
chen Verstärkungsfaktor zu entwerfen. Deshalb wird oft ein allgemeiner Verstärker 
verwendet, der einfach auf den benötigten Verstärkungsfaktor eingestellt werden 
kann. Solch ein allgemeiner Verstärker heißt Operationsverstärker (engl. Opera- 
tional Amplifier, kurz Op-Amp). Op-Amps sind auf einen sehr großen maximalen 
Verstärkungsfaktor ausgelegt. Die tatsächlich benötigte Verstärkung kann durch die 
passende Auswahl einiger Hardwarekomponenten in der zugehörigen Schaltung ein- 
gestellt werden. 

Genauer betrachtet, ist ein Operationsverstärker eine Komponente mit zwei Si- 
gnaleingängen und einem Signalausgang. Zusätzlich hat ein Operationsverstärker 
noch mindestens zwei Eingänge für die Spannungsversorgung (siehe Abb. B.3). 


Abb. B.3 Operationsverstärker Versorgungsspannung 
op-amp 
Vv. == 
V t Vout 
Masse * 


Operationsverstärker verstärken die Differenz zwischen den Spannungen an den 
beiden Signaleingängen bezogen auf das Massepotential um einen Faktor g: 


Vout = & * (V+ = V_) (B.7) 


g wird die Leerlaufverstärkung genannt. Diese ist meist sehr groß (10* < g < 10°), 
bei einem idealen Op-Amp würde sie unendlich erreichen. Weiter verfügen Op-Amps 
normalerweise über eine sehr hohe Eingangsimpedanz (> 1MQ). Daher können wir 
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bei der Betrachtung dieser Bauteile Eingangsströme für gewöhnlich vernachlässigen. 
Bei einem idealen Operationsverstärker wäre die Eingangsimpedanz unendlich und 
damit die Eingangsströme gleich Null. 

Operationsverstärker sind seit vielen Jahrzehnten kommerziell verfügbar, sowohl 
als integrierte Schaltungen wie auch als Teile anderer Schaltungen. Die verfügbaren 
Modelle unterscheiden sich in Geschwindigkeit, Spannungsbereichen, maximalem 
Ausgangsstrom und weiteren Eigenschaften. Der tatsächliche Verstärkungsfaktor 
der Schaltung wird mit externen Widerständen eingestellt. Abb. B.4 zeigt, wie dies 
erfolgen muss. 


Abb. B.4 Operationsverstärker ı RY 
mit Rückkopplung >] 
R 
|. 
op-am 
v - p 
| Vy Vout 


Jede noch so kleine Spannungsdifferenz zwischen den beiden Signaleingängen 
wird um einen großen Faktor verstärkt. Die entstehende Ausgangsspannung wird 
über den Widerstand Rı zurückgekoppelt. Diese Rückkopplung geht an den inver- 
tierenden Eingang, damit ergibt jede positive Spannung V_ eine negative Spannung 
Vout und umgekehrt. Damit arbeitet die Rückkopplung durch die große Verstärkung 
stark gegen die Eingangsspannung an. Die Rückkopplung senkt also die Spannung 
am Eingangskontakt. Die Frage ist, um wie viel? Wir können die Kirchhoffschen Re- 
geln anwenden, um die sich ergebende Spannung V_ zu berechnen (siehe Abb. B.5). 


Abb. B.5 Operationsverstärker 
mit Rückkopplung 
(Masche hervorgehoben) R 


Wegen der Eigenschaften von Operationsverstärkern gilt 


Vout = 78 * V- (B.8) 
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Die Maschenregel für die mit einer gestrichelten Linie markierte Masche in Abb. B.5 
ergibt 


I*Rı + Vour -V-=0 (B.9) 


Wir verwenden hier ein Minuszeichen für V_, da wir einen Abschnitt der Masche 
entgegen der Pfeilrichtung betrachten. Aus den Gleichungen (B.8) und (B.9) ergibt 
sich dann 


I*Rı +(-8)*V_-V_=0 (B.10) 
(1+g)*V_=I«Rı (B.11) 

Ix R 
a B.12 
x l+g ( ) 

I*R 

ideal = B.1 
ser BY) 
=0 (B.14) 


Damit ist für einen idealen Operationsverstärker der Wert von V_ gleich 0. Daher wird 
der invertierende Signaleingang auch virtuelle Masse genannt. Dennoch darf dieser 
Anschluss nicht mit der Masse verbunden werden, da dies die Ströme verändern 
würde. 

Die Berechnung der tatsächlichen Verstärkung in Abb. B.4 ist eine Ubungsaufgabe 
zu Kapitel 3. 


Anhang C 


Seitenadressierung und 
Speicherverwaltungseinheiten 


In diesem Anhang präsentieren wir eine Basistechnik zur Speicherverwaltung, die 
eine Grundlage des Verständnisses moderner Ausfiihrungsplattformen ist. In sehr 
einfachen Rechensystemen werden die physikalischen Speicher tatsächlich mit den 
Adressen adressiert, die vom (Assembler-) Programmierer gesehen werden. Aus 
reiner Hardwaresicht ist dieser Ansatz einfach zu realisieren. Die Nutzung leidet 
allerdings unter einer Reihe von Nachteilen: so ist beispielsweise die Zuordnung von 
Objekten zum Speicher sehr statisch und während der Ausführung kaum zu ändern. 
Daher muss die Größe der Objekte vor der Zuordnung von Speicher bekannt sein 
oder zumindest relativ gut abgeschätzt werden können. 

Mehr Flexibilität wird erreicht, wenn wir unterscheiden zwischen den Adressen, 
welche der (Assembler-) Programmierer sieht, und den Adressen, mit denen wirklich 
der Speicher adressiert wird. Die Adressen, welche der Programmierer sieht, heißen 
virtuelle Adressen. Die Adressen, mit denen der Speicher adressiert wird, heißen 
reale Adressen. 

Bei der Seitenadressierung (engl. paging) partitionieren wir den Raum der 
virtuellen Adressen in Blöcke gleicher Größe, genannt Seiten. Die Größe dieser 
Seiten ist eine Zweierpotenz, z.B. 2kBytes oder 4kBytes. Daher bestehen virtuelle 
Adressen aus den Bits, die eine bestimmte Seite adressieren, sowie aus den Bits, 
die ein bestimmtes Wort oder Byte innerhalb der Seite adressieren. Die erste Menge 
der Bits heißt Seitennummer, die zweite Offset. Der physikalische Speicher wird in 
Blöcke gleicher Größe partitioniert, die Seitenrahmen (engl. page frames) genannt 
werden. 

Mit Hilfe einer sogenannten Seitentabelle (engl. page table) kann man nun den 
Seitennummern Anfangsadressen des korrespondierenden Blocks im physikalischen 
Speicher zuordnen. Der Offset ist für virtuelle und reale Adressen identisch (siehe 
Abb. C.1 (links)). Dies erlaubt eine dynamische Zuordnung von Objekten zum 
Speicher. Zusammenhängende Bereiche im virtuellen Adressraum müssen nicht 
mehr zusammenhängenden Bereichen im realen Adressraum zugeordnet werden 
(siehe Abb. C.1 (rechts)). 

Es kann mehr als einen virtuellen Adressraum geben, beispielsweise je einen 
Adressraum für jeden Prozess, der dem Betriebssystem bekannt ist. In diesem Fall 
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virtuelle Adresse virtueller physikalischer 
Adressraum Adressraum 
Seite Offset a 
M 1 ——7 
Seitentabelle 
y 
frame Offset 


reale Adresse ane 


Abb. C.1 Seitenadressierung: links: Adressberechnung; rechts: Abbildung der Adressräume 


muss beim Prozesswechsel jeweils dafür gesorgt werden, dass ein Verweis auf die 
relevante Seitentabelle gesetzt wird. Die Abbildung von virtuellen Adressen auf rea- 
le Adressen wird typischerweise durch eine spezielle Speicherverwaltungseinheit 
(engl. Memory Management Unit (MMU)) unterstützt. Die MMU befindet sich zwi- 
schen den Prozessoren und dem Speicher. Sie übersetzt virtuelle Adressen in reale 
Adressen. Für ihre Arbeit benötigt die MMU die Kenntnis der jeweils relevanten 
Seitentabelle. Die Seitentabellen können groß werden und daher können spezia- 
lisierte schnelle und kleine Puffer für diese Tabellen erforderlich werden. Solche 
Puffer nennt man Translation Look-aside Buffers (TLB) oder Address Translation 
Memories (ATM). Für häufig benutzte Seitennummern sollen TLBs die benötigten 
Adressumrechnungs-Informationen enthalten. 

Für PCs wird der beschriebene Ansatz häufig mit demand paging kombiniert. 
Hier müssen sich nicht alle benötigten Seiten auch im Hauptspeicher befinden. Wird 
auf eine Seite zugegriffen, die sich nicht im Hauptspeicher befindet, spricht man 
von einem Seitenfehler (engl. page fault). In einem solchen Fall muss die benötigte 
Information von einem langsameren Hintergrundspeicher nachgeladen werden. Der 
Begriff paging wird häufig mit demand paging gleichgesetzt. Allerdings ist es für 
eingebettete Systeme wichtig, zwischen der reinen Partitionierung von Adressberei- 
chen in Seiten und Seitenrahmen sowie dem automatischen Nachladen von einem 
Hintergrundspeicher zu unterscheiden. Paging ist auch für den Speicherschutz nütz- 
lich. Seitentabellen enthalten häufig auch Informationen über Zugriffsrechte für den 
jeweiligen Eintrag. So können wir zwischen Lese-, Schreib- und Ausführungsbe- 
rechtigungen unterscheiden. Damit ist es möglich, die Adressbereiche zu schützen, 
beispielsweise indem einem Prozess nur Leserechte eingeräumt werden. So kön- 
nen fehlerhafte, kompromittierende und/oder sicherheitskritische Zugriffe vermie- 
den werden. Der zweite Aspekt wird beim Internet der Dinge zunehmend wichtig. 
Weitere Informationen zur Speicherverwaltung können in Büchern zur Rechnerar- 
chitektur (siehe z.B. Hennessy et al. [212]) nachgelesen werden 
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